Re: [Samba] Problem with Samba 4.5.8 as a macOS server
- Date: Tue, 4 Apr 2017 16:30:17 +0200
- From: Frank Heldt via samba <samba@xxxxxxxxxxxxxxx>
- Subject: Re: [Samba] Problem with Samba 4.5.8 as a macOS server
Thank you for your fast response!
> Am 03.04.2017 um 19:24 schrieb Ralph Böhme <slow@xxxxxxxxx>:
> On Mon, Apr 03, 2017 at 03:46:49PM +0200, Frank Heldt via samba wrote:
>> Hello all,
>> I’m trying to use samba 4.5.8 as a file server for my Macs (all 10.12.4 now), as a replacement for netatalk.
>> I did setup smb.conf as suggested
>> # Options for macOS
>> # http://netatalk.sourceforge.net/wiki/index.php/Netatalk_3.1.11_SRPM_for_Fedora_and_CentOS <http://netatalk.sourceforge.net/wiki/index.php/Netatalk_3.1.11_SRPM_for_Fedora_and_CentOS>
>> ea support = yes
>> vfs objects = btrfs catia fruit streams_xattr
> btrfs should be put to the end of the list.
Putting it at the end of the list resulted in smb core dumping :-(
>> fruit:encoding = native
>> streams_xattr:store_stream_type = no
>> streams_xattr:prefix = user.
> please be aware that the last two options are seldomly used and currently not
> tested in out test-suite. They should work, but ymmv.
As I explained, this share was a netatalk share and I wanted to retain esp. the tags. This setting did it :-)
>> # don’t use unix ext.
>> unix extensions = no
> 10.12 Macs will use SMB3 and this option is (atm) a SMB1 thingy, so it has no effect.
You’re right, this was a leftover from my first tests. I was playing with cifs:// mounting (this is SMB1 where the setting makes indeed a difference). But then I realised that we loose all the performance gains with SMB1...
>> and a share
>> path = /data/Transfer
>> public = yes
>> writable = yes
>> printable = no
>> create mask = 0775
>> directory mask = 0775
>> Switching between afp:// and smb:// on the Mac looks exactly the same (eg Tags
>> are seen on both sides), the performance under Finder via smb:// for this
>> share is visibly faster (lots of files there). So that’s perfect :-)
>> The problem is the create/directory mask: it is totally ignored! Every
>> file/folder I create via smb has no group write access, although the mask
>> should give it this. Even the force modes are ignored.
> Please try setting the global option
> fruit:nfs_aces = no
And that’s exactly what I was looking for! Works like a charm :-)
Thanks a lot for the hint!
> Alternatively you can set the global umask on the clients to 0 (instead of the
> default 022).
Changing the umask on the clients can be dangerous, as it is a „global" setting. I only wanted to change it for this share.
Again, thanks a lot :-)
To unsubscribe from this list go to the following URL and read the