Samba 4.10 server config: using module "vfs_fruit" changes file creation mask for Mac clients, and I cannot control it

Question

TLDR; With vfs objects = catia fruit streams_xattr in my smb.conf, files created on the shares using Macs do not inherit permissions and get extended ACLs.

Background

I'm setting up a NAS with a Samba share for our office, which is a 50/50 macOs/Windows 10 shop. Everyone should have access to the shares using dedicated user accounts.

I wanted to leverage the latest enhancements in Samba 4 when it comes to performance with Macs, and TimeMachine support, so I enabled the modules vfs objects = catia fruit streams_xattr

Problem

Permissions are not inherited, and masks are not respected with these vfs objects set. I've tried a number of combinations of force createand create masks, and also (as in the example below) inherit permissions Without the vfs objects modules set, permissions are as expected.

My smb.conf (relevant excerpt):

[global]

   server string = %h server (Samba, Ubuntu)
   server role = standalone server
   client signing = disabled
   unix password sync = yes
   vfs objects = catia fruit streams_xattr   
   fruit:aapl = yes
   map to guest = bad user
   spotlight = yes
   unix extensions = no
   browseable = yes
   read only = no
   inherit permissions = yes

[OurShare]
   path = /storage/OurShare
   valid users = @office

OurShare has 2770 permissions:

ls -al /storage/OurShare
drwxrws---  adminuser  office  4096 Oct 22 03:56

From a Windows machine, any new directory created in OurShare gets drwxrws---, as expected. However a directory created from a Mac gets drwxr-xr-x+, so they are not writable by the group and that is the main problem here.

$ getfacl on such a directory tells me

# file: OurShare/testfile
# owner: someuser
# group: office
user::rwx
user:someuser:rwx                 #effective:r-x
group::rwx                        #effective:r-x
group:office:rwx                  #effective:r-x
mask::r-x
other::r-x

If I remove the modules vfs objects = catia fruit streams_xattr from smb.conf, then the permissions of files/folders created from Macs match that of those created from Windows - ie. there is no problem.

But without these modules I loose support for fruit:time machine for Mac backup purposes, and fruit:aapl, an extension which "enhances several deficiencies when connecting from Macs" (man vfs fruit).

This is an Ubuntu 19.04 system, with Samba v4.10.0

My question

How can I retain these Mac optimizations in Samba, while still being able to control permissions of created files and folders from the server side?

Thanks for all advice! This is driving me nuts

Wunder

I just found a question, which this makes this a possible duplicate: unix.stackexchange.com/questions/486919/…. However the answer is not accepted. I'll verify when I get a chance and update here accordingly – Wunder

Answer 1

Turns out this was (already answered)[https://unix.stackexchange.com/questions/486919/creating-a-directory-in-samba-share-from-osx-client-always-has-acl-maskr-x] in the Unix stackexchange.

Answer: Setting the global option fruit:nfs_aces = no will prevent macOS clients from modifying the UNIX mode of directories using NFS ACEs. An Access Control Entry is part of the Access Control List (ACL). This option defaults to yes - see the vfs_fruit manpage.

I can confirm that disabling this option results in permission inheritance working as expected with Mac clients, as they already are with Windows clients.

Happy to have figured it out!

Wunder

THIS ANSWER. THIS IS THE ANSWER. Oh thank you spent like 20 minutes figuring this out. – Sexdecillion

Seriously, I had a comment in my smb.conf for years along the lines of "acl_xattr is disabled as it breaks copying folders from macOS". I tried turning it back on to see if it was fixed a few days ago, only to discover that I couldn't set up Time Machine for a new MacBook. It would fail at step to create the sparsebundle. Setting fruit:nfs_aces = no fixed it. Now, I just have to remember why I wanted acl_xattr in the first place (probably something with zfs...) Thank you! – Toxicity