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
smb.conf.gz
Description: GNU Zip compressed data
