Finally solved a problem that has been causing me much grief. We have a fileserver running CentOS Linux with Samba used to provide file shares to our desktops – a mixture of Windows, Mac and Linux. For some reason the file server was not setting the correct permissions on files copied onto it – using 644 (rw-r–r–) instead of 664 (rw-rw-r–). The consequence of this was that only the person that create the file (or similarly directory) could edit it or move it to another directory (unless they owned that directory). This is something that I’m sure used to work for us, so I was a bit puzzled to hear reports of the problem.
Normally setting either the “force create mode” and “force directory mode” options in the smb.conf configuration file, or using “inherit permissions” ensures that the correct permissions are set. The former option can be set to 664 / 775 respectively and will ensure that files copied onto the server get the right permissions – in particular the group write bit is set allowing any user (who has access to the file) to write it, or for a directory to copy other files into that directory. The latter option ensures that new files inherit the permissions of their parent, so assuming that the system starts with the correct permissions on everything, all new files should continue to have the right permissions.
In the end I decided to upgrade the server as we were running an old version of CentOS and it was beneficial to do it anyway. However, after upgrading and running some tests the problem still persisted. Very frustrating as there are lots of postings of people having similar issues, and they always get resolved by setting the above options.
Finally, I managed to get to the bottom of the issue. It seems that Samba has a feature that allows Unix clients to perform additional operations. OS/X takes advantage of this in Leopard (and now Snow Leopard I imagine) and resets the permissions on the file after it is created. So it doesn’t matter (with the exception of the below) what options you set in smb.conf – any files created from recent Macs will have the wrong permissions. Most of our heavy users of the server use OS/X and so what I thought was an issue prevalent to everyone actually was specific to one operating system.
Looking around the web, I came across a post in the Apple support forums with the solution – set “unix extensions = no” in the global section of smb.conf and restart Samba. One simple line and suddenly everything is back to how it was. Reading around it appears to be an issue that is being resolved – although I imagine it will take a few months before it appears in mainstream releases.
Wanting to try this fix, but I have a question.
Is the smb.conf file located on the actual Linux box? Or is that something you change on the actual mac (in the local smb.conf file).
This is the smb.conf file on the Linux box (so the server). Hope the fix works for you.
Thanks for getting back to me. Just wanted to let you know that I ended up changing the local smb.conf file (located on my mac “var/db/smb.conf”) and it seems to have worked as well… My network admin is a little ‘fussy’ about changing anything on his precious linux servers.
whew, been a long few months dealing with these permission issues…
No problem – glad you got it resolved 🙂
news from the front – still having issues – but they are different than before. I’ll keep you updated.
Under Leopard you could set ACL permissions to “inherit” permissions from the parent, but this appears to be gone in Snow Leopard (though it might still be in Server 10.6.
This is causing no end of issues with shared folders, i.e. through Dropbox.
If anyone knows of a way to set inherit permissions in snow leopard, (outside of Samba) pleas let us all know. There is not a single app in version tracker to manipulate ACLs in OSX, which could make that a nice project for a knowledgeable person.
We’ve not started using Snow Leopard here, nor are we using ACLs – although it is something I’d like to do. Sounds like another issue to be overcome when we get there!
I can think of a quick hack that might work for your Dropbox – small cronjob to periodically sort out the permissions on new files as they are added?
Thanks so much for this clear and simple explanation. You saved me a lot of head-scratching!
Thank you! Thank you! Thank you! This was making me so angry. I finally found this post and got it worked out. At first I was putting the unix extensions = no in the share section, but once I moved it to the [global] section as per your instructions it worked!
@Bart B @Andrew P – no problem, glad it was useful.
Egads. I was starting to bleed from the eyes on this one. Thanks! 🙂
You saved meeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
Thank you so much!
I’m making a blog on my Tonido Plug with some tutorials based on my (nerd) experiences.
I’ll quote this page on my blog! (For any questions or problems, please contact me and we’ll solve it!)
Thanks for the link Sergio – your blog looks very informative, especially for non-English speakers who must find it difficult finding information.
shame I have gone though setting up linux perms Acl’s and the smb.conf. to find I still have a problem.
Mac’s …….. …. …
Thanks! It worked like a charm after 3 days of nearly pulling my hair out!
Great thanks for this info.
Apparently as of now, Ubuntu and Mac’s are still having the problem and this solved an issue that the previous IT guy could never solve. Finding this tidbit may have saved my job! THANK YOU!
Glad you found it useful. Amazed it still hasn’t been resolved.
It worked well.
Server: GNU / Linux Debian Lenny
Client: Mac OS X Leopard (10.5)
It worked here too.
Server : Linux Debian Lenny
Client : Mac OS X 10.6.8
Thanks for this. It fixed my similar problems with FreeNAS. You can enter the option into auxiliary parameters in the GUI.
Thanks for the helpful post.
Work for me – mac os 10.9, and another linux i think.