Mac clients cannot set permissions on Samba share

Question

I'm running Samba on a Debian server in my local home network. The Samba version is 4.9.5-Debian. My Mac Mini (with Big Sur) connects to that server. There is a share for time machine backups and another one for storing data. Time machine backups seem to work (at least Time Machine does not complain and I successfully restored single files from backups).

However, I noticed that permissions on the data share do not work properly. If I try to change permissions of a file or folder, e.g., with chmod 640 testfile.txt, then permissions on the share are not affected. Permissions always stay the same.

I already tried various Samba settings based on information I found on the Internet, as well as reading man smb.conf and man vfs_fruit.

I added these parameters to the global section of my smb.conf file:

   server min protocol = SMB3_00
   ea support = yes
   vfs objects = acl_xattr catia fruit streams_xattr
   fruit:aapl = yes
   fruit:metadata = netatalk
   fruit:resource = file
   fruit:encoding = native
   fruit:copyfile = yes
   fruit:model = MacSamba
   fruit:veto_appledouble = no
   fruit:posix_rename = yes
   fruit:zero_file_id = yes
   fruit:wipe_intentionally_left_blank_rfork = yes
   fruit:delete_empty_adfiles = yes
   fruit:nfs_aces = no

And the data share is configured like this:

[DataShare]
   comment = Samba data share
   path = /srv/samba/datashare
   browseable = yes
   read only = no
   guest ok = no
   valid users = myuser
   create mask = 0777
   directory mask = 0777

I'm new to Samba and am a bit confused by all the different parameters. Right now I don't have any idea why my Mac client cannot set file permissions for files on the share.

For simply storing files this might even be OK, but it causes problems with applications. As an example, I wanted to put my large picture library on to the share. I copied it there and wanted to open it with Apple's Photos app - but Photos fails to do so, says permissions are broken, and also fails to repair permissions.

I'd really appreciate some help, because I'd love to get this setup working.

Answer 1

I'm late to this, but I can't be the person that discovered a solution that worked (for me, at least) without putting it out there, since I've been that guy that screams at the "nvm fixed it" comments with no elaboration ;)

Your very first step is to check your fstab. You need to make sure you have

1. Enabled xattrs support on the filesystem you're sharing from, check your fstab.

2. Enabled ACL in mount options too, while you're there. Something like this, adjust for your environ:

   /dev/disk/by-label/nas1 /mnt/nas1 ext4 defaults,user_xattr,acl,commit=60 0 2
   

   I just went through a couple of hours of troubleshooting why I got permission errors. I had simply forgotten point 2.

The rest of my setup was already OK with much less fuss than I thought:

3. Put this in smb.conf [global] section:

   [global]
   vfs objects = fruit catia streams_xattr acl_xattr
   map acl inherit = yes
   fruit:aapl = yes
   fruit:model = MacSamba
   fruit:metadata = stream
   readdir_attr:aapl_rsize = yes
   readdir_attr:aapl_finder_info = yes
   readdir_attr:aapl_max_access = yes
   

   If you wonder what the settings do, I humbly suggest you $> man smb.conf (not a dig at the OP, I confused the text in their post with another more... ignorant post previously.)

The rest of the file can stay default. Change your workgroup name if you're an old Windows 3.11 guy that cares about syncing that across my LAN.

4. In the share you want to have tag support for, these options work well for me:

   [Pr0n]
     comment = Pr0n
     path = /mnt/nas1/Pr0n
     browseable = no
     guest ok = no
     read only = no
     writable = yes
     valid users = 
   
   [ -- snip -- ]
   
     force directory mode = 0775
     force create mode = 0664
   
     # Fruit config
     fruit:posix_rename = yes
     fruit:veto_appledouble = yes
     fruit:nfs_aces = yes
     fruit:wipe_intentionally_left_blank_rfork = no
     fruit:delete_empty_adfiles = no
   

The directory is owned by my personal user and group, I did not need to fuddle around with net grant SeDiskOperatorStatus or any of that.

One reboot later (might as well, right) everything was automagically good, and tags are both allowed and stick.

Answer 2

It is possible that your PAM (Pluggable Authentication Module) setting is overrules your directory mask and create mask settings. Check the line: obey pam restrictions = no in your smb.conf.Should do the trick.