Mac fruit settings are not consistently assigned to SMB shares.

[Philip Robar]

I've read the TrueNAS 12 and Mac discussions that seem to be related to the problems I seeing by searching on "smb fruit". Some reports might be related, but I didn't find this specific problem mentioned.

In a fresh install of TrueNAS 12.0 Release some of my SMB shares have fruit settings and some don't which appears to be keeping Time Machine backups from working and causes some shares to mount with no access permitted. (Red circles with a dash on all of the folders.)

The Apple SMB extensions are enabled in the SMB service GUI (By default, I didn't set it?) and the GUI setting for all of my shares are identical except for the TimeMachine share: "Default share parameters" and "Allow Guest Access". The Time Machine share has "Multi-user time machine" set and Guest access is not set.

The only the services that I have enabled are ssh, SMB and SMART.

I don't remember the order in which I created the shares was, but I'm pretty sure that the three TV shares (which have no fruit settings) were first. Deleting and recreating the three TV shares resulted in them having fruit settings and being accessible.

Code:

root@truenas[~]# testparm -a
Load smb config files from /usr/local/etc/smb4.conf
Loaded services file OK.
WARNING: some services use vfs_fruit, others don't. Mounting them in conjunction on OS X clients results in undefined behaviour.

Server role: ROLE_STANDALONE

Press enter to see a dump of your service definitions

# Global parameters
[global]
    aio max threads = 2
    bind interfaces only = Yes
    disable spoolss = Yes
    dns proxy = No
    enable web service discovery = Yes
    kernel change notify = No
    load printers = No
    logging = file
    map to guest = Bad User
    max log size = 51200
    nsupdate command = /usr/local/bin/samba-nsupdate -g
    registry shares = Yes
    server role = standalone server
    server string = TrueNAS Server
    unix extensions = No
    username map = /usr/local/etc/smbusername.map
    username map cache time = 60
    idmap config *: range = 90000001-100000000
    fruit:nfs_aces = No
    idmap config * : backend = tdb
    directory name cache size = 0
    dos filemode = Yes


[TV2]
    comment = TV1
    ea support = No
    guest ok = Yes
    kernel share modes = No
    path = /mnt/TV2/TV2
    posix locking = No
    read only = No
    vfs objects = aio_fbsd streams_xattr shadow_copy_zfs ixnas
    nfs4:chown = true


[TV1]
    comment = TV1
    ea support = No
    guest ok = Yes
    kernel share modes = No
    path = /mnt/TV1/TV1
    posix locking = No
    read only = No
    vfs objects = aio_fbsd streams_xattr shadow_copy_zfs ixnas
    nfs4:chown = true


[TV3]
    comment = TV3
    ea support = No
    guest ok = Yes
    kernel share modes = No
    path = /mnt/space/TV3
    posix locking = No
    read only = No
    vfs objects = aio_fbsd streams_xattr shadow_copy_zfs ixnas
    nfs4:chown = true


[Space]
    comment = Space
    ea support = No
    guest ok = Yes
    kernel share modes = No
    path = /mnt/space/space
    posix locking = No
    read only = No
    vfs objects = aio_fbsd fruit streams_xattr shadow_copy_zfs ixnas
    fruit:metadata = stream
    fruit:resource = stream
    nfs4:chown = true


[TimeMachine]
    comment = Time Machine
    ea support = No
    kernel share modes = No
    path = /mnt/space/TimeMachine/%U
    posix locking = No
    read only = No
    vfs objects = aio_fbsd tmprotect fruit streams_xattr shadow_copy_zfs ixnas
    ixnas:default_user_quota = 1T
    ixnas:zfs_auto_homedir = true
    fruit:locking = none
    fruit:time machine = yes
    fruit:resource = stream
    fruit:metadata = stream
    nfs4:chown = true


[Media]
    comment = Media other than Movies and TV
    ea support = No
    guest ok = Yes
    kernel share modes = No
    path = /mnt/space/media
    posix locking = No
    read only = No
    vfs objects = aio_fbsd fruit streams_xattr shadow_copy_zfs ixnas
    fruit:resource = stream
    fruit:metadata = stream
    nfs4:chown = true

 

[seanm]

some of my SMB shares have fruit settings and some don't

Don't do that.

11. Sharing — FreeNAS®11.2-U3 User Guide Table of Contents

www.ixsystems.com

"Be careful when using multiple SMB shares, some with and some without fruit. macOS clients negotiate SMB2 AAPL protocol extensions on the first connection to the server, so mixing shares with and without fruit will globally disable AAPL if the first connection occurs without fruit."

 

[anodos]

Are there any auxiliary parameters set on share [TV1] or [TV2]?
I think this may be a bug that I fixed in U1. If there are not aux parameters, then try making a small modification to share config (for instance the "comment").

There is a global setting "enable apple smb extensions" under Services->SMB. This should be checked (ensures that Fruit will get applied to all shares).

 

[Philip Robar]

Don't do that.

I didn't the GUI/middleware did.

 

[Philip Robar]

Are there any auxiliary parameters set on share [TV1] or [TV2]?
I think this may be a bug that I fixed in U1. If there are not aux parameters, then try making a small modification to share config (for instance the "comment").

There is a global setting "enable apple smb extensions" under Services->SMB. This should be checked (ensures that Fruit will get applied to all shares).

I just checked, none of the shares have any aux parameters.
Deleting and recreating the shares fixed the problem
As I noted above the Apple extensions are enabled on the SMB service.

Given all the stuff that is coming in U1, I figured that there was a good chance that this would also be fixed. I just wanted to make sure that someone was aware of the issue.

Thank you for responding.

 

[wsd33904]

Hi! I wanted to chime in here, as I spent hours with exact same symptoms as the original poster. Thanks for posting about this!

I also had some shares that had vfs objects = fruit in the smb registry, and others didn't. This can be checked by running net conf list in the shell.

This caused me intermittent problems when connecting to my FreeNAS share on my iMac. If I authenticated and first navigated to a share that had didn't have fruit enabled, then I could navigate all shares perfectly. If I authenticated and first navigated to a share that did have fruit enabled, then any shares that didn't have fruit enabled would error out with what Phillip mentioned: red circles with a dash on all of the folders in the share, with the error message "The folder ... can’t be opened because you don’t have permission to see its contents." This falls in line with the comment in the documentation:

Be careful when using multiple SMB shares, some with and some without fruit. macOS clients negotiate SMB2 AAPL protocol extensions on the first connection to the server, so mixing shares with and without fruit will globally disable AAPL if the first connection occurs without fruit. To resolve this, all macOS clients need to disconnect from all SMB shares and the first reconnection to the server has to be to a fruit-enabled share.

Source: https://www.ixsystems.com/documentation/freenas/11.2/sharing.html#windows-smb-shares

Seems like the inconsistency with the protocol extensions messes with how Finder sees the permissions. Not sure why though.

My theory is that whenever you enable "Enable Apple SMB2/3 Protocol Extensions" for SMB, that only configures shares that you make after the fact, and does not modify the shares you made before. This at least falls into line with the inconsistencies that I saw.

Looking forward to the issue being fixed! I hope this helps anyone with the same frustrations.

 

[Newfoundland.Republic]

Would the samba.org's docs on this help: Configure Samba to Work Better with Mac OS X?

 

[anodos]

Hi! I wanted to chime in here, as I spent hours with exact same symptoms as the original poster. Thanks for posting about this!

I also had some shares that had vfs objects = fruit in the smb registry, and others didn't. This can be checked by running net conf list in the shell.

This caused me intermittent problems when connecting to my FreeNAS share on my iMac. If I authenticated and first navigated to a share that had didn't have fruit enabled, then I could navigate all shares perfectly. If I authenticated and first navigated to a share that did have fruit enabled, then any shares that didn't have fruit enabled would error out with what Phillip mentioned: red circles with a dash on all of the folders in the share, with the error message "The folder ... can’t be opened because you don’t have permission to see its contents." This falls in line with the comment in the documentation:

Seems like the inconsistency with the protocol extensions messes with how Finder sees the permissions. Not sure why though.

My theory is that whenever you enable "Enable Apple SMB2/3 Protocol Extensions" for SMB, that only configures shares that you make after the fact, and does not modify the shares you made before. This at least falls into line with the inconsistencies that I saw.

Looking forward to the issue being fixed! I hope this helps anyone with the same frustrations.

Can you PM me a debug? The previously created shares should also be altered, but I need a clear reproduction case for your issue. If "vfs objects" are for some reason defined in auxiliary parameters, then unexpected results may happen.

 

[wsd33904]

Would the samba.org's docs on this help: Configure Samba to Work Better with Mac OS X?

To fix the problem, like Philip, I deleted and re-added the shares that I had added before I selected "Enable Apple SMB2/3 Protocol Extensions". Also, to help with performance, I visited your link and added the parameters I saw to the SMB service's auxiliary parameters.

Can you PM me a debug? The previously created shares should also be altered, but I need a clear reproduction case for your issue. If "vfs objects" are for some reason defined in auxiliary parameters, then unexpected results may happen.

PMed you with more details.

 

[vvuk]

Adding to old thread -- I just ran into this issue on 12.0-U7. Apple Extensions were enabled, but I somehow had a bunch of shares that didn't have fruit, and one that did. Oddly my actual time machine share was brand new and _didn't_ have fruit:

Code:

tank% sudo net conf list | grep vfs
    vfs objects = streams_xattr shadow_copy_zfs ixnas aio_fbsd
    vfs objects = streams_xattr shadow_copy_zfs ixnas aio_fbsd
    vfs objects = streams_xattr shadow_copy_zfs ixnas aio_fbsd
    vfs objects = fruit streams_xattr shadow_copy_zfs ixnas aio_fbsd
    vfs objects = tmprotect streams_xattr shadow_copy_zfs ixnas aio_fbsd

I don't think this server ever had anything before 12.0 installed on it.

To resolve this, I turned off SMB extensions in the SMB config & saved, which removed fruit from everything (well, the one share that had it). Then I enabled SMB extension & saved, which added fruit to all vfs object lists, and Time Machine is happy now.