Permissions issues with a samba share and the OSX Finder

[f4242]

Hello,

I have a strange problem with two mac users. One is using an old 10.7 OSX and the other is using 10.10. I have others mac users without any problems. I installed a mac with osx 10.10 and was not able to replicate my problem using the same user credential.

So, I have a SMB share on my FreeNAS 11 server. User can copy the file from the share to their computer but are then unable to open it. When they try to open the file, they receive a message about missing permissions. The file is greater than 0 bytes, so the file successfuly copied on the local computer. I can also open it with a text editor with the terminal (so I assume this is a bug related with the Finder). If I right click on the file and see information about the file, I see there is only one permission set for "everyone" and the permission is set to forbidden.

When I do a "ls" with the terminal to list file in the share directory (in /Volumes), I see that permissions are all set to "---------" (no permissions set). When I do the same thing on other mac computer, I get "rw-rw----". The permissions set on the server are:

# owner: root
# group: wheel
group:acces_projets:rw-p-daARWc---:------I:allow
group:enterprise admins:rwxpDdaARWcCos:------I:allow
everyone@:--------------:------I:allow
owner@:rw------------:------I:allow
group@:rw------------:------I:allow

The user is member of the acces_projets group.

I tried to enable the vfs_fruit module on my share but this doesn't seem to change anything.

Any idea what is the problem? And why I have one mac working and one not working with the same osx release?

Thanks

 

[anodos]

Hello,

I have a strange problem with two mac users. One is using an old 10.7 OSX and the other is using 10.10. I have others mac users without any problems. I installed a mac with osx 10.10 and was not able to replicate my problem using the same user credential.

So, I have a SMB share on my FreeNAS 11 server. User can copy the file from the share to their computer but are then unable to open it. When they try to open the file, they receive a message about missing permissions. The file is greater than 0 bytes, so the file successfuly copied on the local computer. I can also open it with a text editor with the terminal (so I assume this is a bug related with the Finder). If I right click on the file and see information about the file, I see there is only one permission set for "everyone" and the permission is set to forbidden.

When I do a "ls" with the terminal to list file in the share directory (in /Volumes), I see that permissions are all set to "---------" (no permissions set). When I do the same thing on other mac computer, I get "rw-rw----". The permissions set on the server are:


The user is member of the acces_projets group.

I tried to enable the vfs_fruit module on my share but this doesn't seem to change anything.

Any idea what is the problem? And why I have one mac working and one not working with the same osx release?

Thanks

What permissions type is set on the share?

 

[f4242]

Permission type is set to Windows.

 

[anodos]

Permission type is set to Windows.

Post a debug file "system"->"advanced"->"save debug".

 

[f4242]

The debug file would need some review and cleanup to preserve confidentiality. Do you need specific files?

Thanks.

 

[anodos]

The debug file would need some review and cleanup to preserve confidentiality. Do you need specific files?

Thanks.

..ixdiagnose/fndebug/SMB/dump.txt

and maybe

..ixdiagnose/fndebug/ZFS/dump.txt

 

[f4242]

Let's start with fndebug/SMB/dump.txt.

 

[anodos]

Let's start with fndebug/SMB/dump.txt.

It looks suspiciously like someone performed 'chmod 550' on the root of your share, which shouldn't be possible (or at least shouldn't be happening). The ZFS dump might give more insight.

How are you setting permissions? The permissions of owner@ by default should be rwxpDdaARWcCos:fd-----:allow i.e. "full control" with the inheritance bits set.

It's possible that the Mac's SMB client in 10.7 is not very good. Isn't that the version in which Apple decided to 'roll their own'? I don't think that the SMB2 AAPL extensions existed (vfs_fruit provides support for AAPL extensiosn) when 10.7 was released. This might also be a problem. 10.7 might be using a janky implementation of SMB1 Unix extensions to interact (badly) with the posix mode bits on your share. It's hard to say without viewing log.smbd with logging turned way up. The ZFS dump might provide a piece of the puzzle. The behavior can also be explained by someone messing with the ZFS 'aclmode' property.

 

[f4242]

It looks suspiciously like someone performed 'chmod 550' on the root of your share, which shouldn't be possible (or at least shouldn't be happening). The ZFS dump might give more insight.

How are you setting permissions? The permissions of owner@ by default should be rwxpDdaARWcCos:fd-----:allow i.e. "full control" with the inheritance bits set.

This was set with setfacl. Something like setfacl -m owner@:rxaRc:allow. But not sure why I did that... Will check tomorrow if reverting the owner permissions to the default fix the problem or not.

IIt's possible that the Mac's SMB client in 10.7 is not very good. Isn't that the version in which Apple decided to 'roll their own'? I don't think that the SMB2 AAPL extensions existed (vfs_fruit provides support for AAPL extensiosn) when 10.7 was released. This might also be a problem. 10.7 might be using a janky implementation of SMB1 Unix extensions to interact (badly) with the posix mode bits on your share. It's hard to say without viewing log.smbd with logging turned way up. The ZFS dump might provide a piece of the puzzle. The behavior can also be explained by someone messing with the ZFS 'aclmode' property.

OSX 10.7 is quite old, If I can make it working with 10.9+ I'll be happy. I have users with 10.9 and 10.11 without issues. Like I said, I didn't succeeded to replicate the problem on another computer with the same 10.10 release.

 

[anodos]

This was set with setfacl. Something like setfacl -m owner@:rxaRc:allow. But not sure why I did that... Will check tomorrow if reverting the owner permissions to the default fix the problem or not.



OSX 10.7 is quite old, If I can make it working with 10.9+ I'll be happy. I have users with 10.9 and 10.11 without issues. Like I said, I didn't succeeded to replicate the problem on another computer with the same 10.10 release.

Setfacl by default won't recurse through a file tree. You will need to do something like find -type d /mnt/pool0/PROF -exec setfacl -m owner@:full_set:fd:allow {} \; Please test before running on your data. The command should give owner@ full control again.

If a group needs "read only" permissions, then you can configure it by the command setfacl -m g:group:read_set:fd:allow. The inheritance bits "fd" are important because they determine whether the permissions will be inherited on files and directories respectively.

 

[anodos]

Any idea what is the problem? And why I have one mac working and one not working with the same osx release?

It's also important to note that Mac clients will negotiate support for SMB2-AAPL extensions on the first SMB2 TREE_CONNECT. This means that if the Mac receives a SMB2 TREE_CONNECT response from a share without vfs_fruit first, then it will treat all subsequent connections to your server as not supporting them. This results in somewhat inconsistent behavior.

TL;DR - turn on "fruit" for all of your shares.

 

[f4242]

Hi,

I cloned my dataset and created a new test share on it. I ran setfacl with find to revert owner permissions to defaults. I also added vfs_fruit to all my shares. Asked the user to reboot the computer and to try to connect to my test share but unfortunately, this still doesn't work.

 

[anodos]

Hi,

I cloned my dataset and created a new test share on it. I ran setfacl with find to revert owner permissions to defaults. I also added vfs_fruit to all my shares. Asked the user to reboot the computer and to try to connect to my test share but unfortunately, this still doesn't work.

Under Services->SMB increasing logging level to "debug", then reproduce the problem and grab /var/log/samba4/log.smbd then post it here. You should take steps to make sure that the problematic client is the only one connecting to the share when you are generating the log file (it's extremely verbose).

 

[f4242]

Will try that tomorrow. Took a few hours to push the snapshot to another unused FreeNAS box.

Thanks!

 

[f4242]

Finally, I took the easy way : I upgraded the 10.10 user to 10.12. It "fixed" the problem. I will also upgrade the remaining user at 10.7 to 10.9. I have others users running 10.10 and they didn't complaint about problem with the share, but I'll verify with them to be sure. I already know there is two computers at 10.10 that work without any problems... Strange bug! I would like to investigate a little more but unfortunately I miss time to do it right now.

Thank you for your help!

 

[anodos]

Finally, I took the easy way : I upgraded the 10.10 user to 10.12. It "fixed" the problem. I will also upgrade the remaining user at 10.7 to 10.9. I have others users running 10.10 and they didn't complaint about problem with the share, but I'll verify with them to be sure. I already know there is two computers at 10.10 that work without any problems... Strange bug! I would like to investigate a little more but unfortunately I miss time to do it right now.

Thank you for your help!

No problem. I'm glad you found a resolution to the problem.