We recently came across a problem with our file server where I was unable to write to a particular directory on Openfiler. It turned out that this directory was created on a Mac and I was unable to place any files in it from Windows. What's happening?
Some Googling got me to various unanswered posts where people roughly described the same problem although not everyone thinks of the same causes. They report problems with (and on their respective forums/blogs) either Samba, ACL, Windows, Openfiler, Linux kernel, MacOSX, or even the (Mac) Finder application.
So, in Openfiler, we have the users mac_lover and win_lover, both belonging to the same group staff. We are using the SMB / CIFS server in Openfiler to allow access to our shares. We're using an up-to-date version of Openfiler (2.3, with all updates at the time of writing - Samba 3.2.7). On the client side, we have mac_lover using MacOSX, win_lover using Windows Vista (you saw this coming right?).
If mac_lover creates a folder (test_by_mac_lover_from_mac) on the share, win_lover cannot write in it. However, if win_lover creates a folder (test_by_win_lover_from_win), mac_lover can write in it just fine. Frustrating, to say the least! Also, to rule out anything user specific, we let mac_lover connect to the share from a Windows machine and create a folder (test_by_mac_lover_from_win). Yep, win_lover can write in that folder without any problems.
MacOSX and Samba (perhaps in combination with Openfiler) don't work that well together it seems. Let's look at the (regular) permissions:
[root@openfiler ~]# ls -sla /mnt/my_volume_group/my_volume/my_share/ total 72 8 drwxrws--- 15 nobody staff 4096 Aug 22 12:00 . 0 drwxr-xr-x 4 root root 84 Apr 28 15:11 .. 12 -rw-rwx--- 1 mac_lover staff 6148 Aug 22 11:23 .DS_Store 4 drwxrwsr-x 2 mac_lover staff 6 Aug 22 09:19 test_by_mac_lover_from_mac 4 drwxrws--- 2 win_lover staff 6 Aug 22 09:21 test_by_win_lover_from_win 4 drwxrws--- 2 mac_lover staff 6 Aug 22 09:29 test_by_mac_lover_from_win
For some reason, mac_lover gives world readable and execute permissions but that wouldn't matter for win_lover as they are in the same group. Another interesting observation is that the folders are actually owned by the users that created them. If you would update any share settings in Openfiler's GUI, you'll see that all files and folders will suddenly have nobody as owner. But then, what is the problem?
After trying several commands, I found getfacl to show the ACL permissions:
[root@openfiler ~]# getfacl /mnt/my_volume_group/my_volume/my_share/test_by_mac_lover_from_mac getfacl: Removing leading '/' from absolute path names # file: mnt/my_volume_group/my_volume/my_share/test_by_mac_lover_from_mac # owner: mac_lover # group: staff user::rwx group::r-x group:apache:rwx mask::rwx other::r-x default:user::rwx default:group::rwx default:group:apache:rwx default:mask::rwx default:other::--- [root@openfiler ~]# getfacl /mnt/my_volume_group/my_volume/my_share/test_by_win_lover_from_win getfacl: Removing leading '/' from absolute path names # file: mnt/my_volume_group/my_volume/my_share/test_by_win_lover_from_win # owner: win_lover # group: staff user::rwx group::rwx group:apache:rwx mask::rwx other::--- default:user::rwx default:group::rwx default:group:apache:rwx default:mask::rwx default:other::---
Oh that's just nasty! It seems that the test_by_mac_lover_from_mac folder doesn't have write permissions for the group - doh!.
Regardless whether this is a problem with MacOSX or Samba (I don't see anything else to blame), let's fix this! All the information above helped in finding similar problems and possible solutions.
To skip the "not working solutions", the only solution I found was on the Ubuntu forums, posted by sbleono. He proposed to basically set all force and mask options in /etc/samba/smb.conf explicitly (see his post). And, yes, it worked!
Although the above works, it's far from elegant. I continued to play with some more configuration options in the Samba configuration and found a possibly better solution:
Just add inherit owner = yes to the [global] section of your /etc/samba/smb.conf and do a /etc/init.d/smb restart
Creating the same folders this time results in a different set of ACL (and regular) permissions:
[root@openfiler ~]# getfacl /mnt/my_volume_group/my_volume/my_share/test_by_win_lover_from_win getfacl: Removing leading '/' from absolute path names # file: mnt/my_volume_group/my_volume/my_share/test_by_win_lover_from_win # owner: nobody # group: staff user::rwx group::rwx group:apache:rwx mask::rwx other::--- default:user::rwx default:group::rwx default:group:apache:rwx default:mask::rwx default:other::--- [root@openfiler ~]# getfacl /mnt/my_volume_group/my_volume/my_share/test_by_mac_lover_from_mac getfacl: Removing leading '/' from absolute path names # file: mnt/my_volume_group/my_volume/my_share/test_by_mac_lover_from_mac # owner: nobody # group: staff user::rwx group::rwx group:apache:rwx mask::rwx other::--- default:user::rwx default:group::rwx default:group:apache:rwx default:mask::rwx default:other::---
Well look at that. The permissions are completely correct! Even the owner is set to nobody (which Openfiler would do after an update anyway) and mac_lover also doesn't give world read and execute permissions anymore. Unfortunately, this property in smb.conf will be overwritten by Openfiler when you update share permissions. Be sure to place it back whenever you do that.
I noticed that Openfiler "sometimes" generates the Samba configuration file and overwrites the change described above.
To solve that, you can hack a bit at the PHP code used by Openfiler. Not desired, but it does the job. Go edit: /opt/openfiler/var/www/includes/generate.inc, and make the following change:
after line 1847:$ac_smb_fp->AddLine( "preferred master = no"); $ac_smb_fp->AddLine( "os level = 0"); // Added the line below: $ac_smb_fp->AddLine( "inherit owner = yes"); if (strncasecmp($ac_aresult[29], "YES", 3) == 0) {
The above will make sure that everytime the config file is generated, the change is included.
Allow squid/mod_wsgi to pass the HTTP_AUTHORIZATION header to Apache Django "view-permissions" for related objects