[Pkg-samba-maint] Bug#501678: Files copied/moved to cifs filesystems get attributes changed

[Chris Carr]

On Fri, 2008-10-10 at 13:01 -0700, Steve Langasek wrote:
> tags 501678 confirmed upstream
> thanks
> 
> On Thu, Oct 09, 2008 at 02:45:27PM +0100, Chris Carr wrote:
> > Package: smbfs
> > Version: 2:3.2.3-1
> 
> > I'm no expert on samba/cifs but something has changed recently. I've used
> > smbfs for mounting filesystems of other machines on my LAN for years, with
> > no problems once permissions are all sorted out. 
> 
> > In the past year or so I've noticed dozens of files appearing on my console
> > in green (executable) - things like .txt files, which should never get +x. 
> 
> > I've traced this to samba. Now, whenever I copy/move a file onto a mounted
> > smbfs filesystem, or create a new file on such a filesystem, the file
> > automatically gets permissions 755. 
> 
> > Presumably the permissions of new files are controlled by a umask setting
> > somewhere - I can't see one on the manual page of mount.cifs, so maybe it's
> > done in the samba server config. But why would existing files have their
> > attributes changed when they're copied or moved onto a smbfs filesystem?
> > This seems to be a bug - surely samba should not mess with file attributes
> > unless the user explicitly tells it to do so. 
> 
> Are you sure this is happening when you move files?  I see it when I copy
> files, but not when I move them.

Yes. I have just confirmed this by moving a plain text file onto a samba
share (/home/chrisc on the server mounted as /home/chrisc/MyDocs on the
client). Bizarrely, I received the following error message: 

mv: setting permissions for `MyDocs/text.txt': Permission denied

... but still the +x attribute was set! So does that mean it wasn't set
by the mv command, but by the samba server? 

In case it helps, I attach the smb.conf file for the server. 

> The reason for this is that 'mv' or 'cp -p' will explicitly set the file
> mode with fchmod(); if you run 'cp' without the '-p' option, then the mode
> on the new file is not copied separately, it's expected to be set by the
> option passed to open() which comes from the user's umask.
> 
> It looks like this is somehow related to the handling of 'map archive'
> between client and server.  If you set 'map archive = no', then the
> executable bit is not set.

Sorry to be dim, but you mean set that in smb.conf, yes? 

> This is only a workaround, though - it's still a bug if our POSIX client is
> getting the execute bit set when the user isn't asking for it.

Thanks for the reply,

Chris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smb.conf.gz
Type: application/x-gzip
Size: 3562 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-samba-maint/attachments/20081010/a84780d8/attachment-0001.bin