Adam Wunn

Q: SMB Permissions Issues on Shares on Yosemite Server

I know this issue has been rehashed and posted in various ways over the years, but I wanted to put out my experience and specific circumstances to the community. I am also calling Apple support, which I don't think will make any difference, but I am hitting a brick wall, so I need to do something.

I have a customer with a Yosemite 10.10.5 server (running on a 4,1 Mac Pro with a RAID system) and a whole office full of 10.10.5 clients mixed with 5 newer El Crapitan clients (which is extremely buggy, but I digress). Everyone is connecting to the server via SMB and using a number of shares that using POSIX and ACLs for permissions. I have the shares using the local administrator of the server as the owner and the company's named staff group (which I created) as the POSIX group. For permissions I have set the POSIX to 770, with the "everyone" bit set to no access. I have corresponding ACLs for the same admin user and the named staff group set to read and write. I have set the permissions to propagate to all of the child folders and files. When users create a new file or folder they have a default umask of 022 regardless of the fact that I have set them to 002 (which is another thing that drives me nuts - why Apple why), and the ACLs are set correctly, but some times other clients cannot modify the files or delete them. They always have "custom access" when viewed from the Get Info panel on the local computer. Even so, most of the time, the ACLS are respected regardless of the POSIX and the user has proper permissions. However, when things go wrong nothing a local user does ever works. It seems that the clients are at that point ignoring the ACLs and relying solely on POSIX in these cases. If I try to fix it on the server end by modifying the permissions, that will sometimes allow the clients to then modify or delete the files, but in many cases, only a restart of the client computer will clear the problem, and in some cases, I have to move or delete the file on the server end.


 

While this behavior is WAY more common on the El Crapitan clients, it does also happen on Yosemite. When the problem becomes a very common occurrence, what I do to mitigate the nightmare is to strip the ACLs from the shares and all child folders about twice a month and then set the posix permissions to 777 in Terminal.Then I go back to the Server App, and set things up as 775 again and then add in my ACL's and then finally propagate. This tends allow most things to function normally for a time, but I eventually get a few complaints here and there until the problem becomes very common again and I am back to the reset route. I have no idea why the stripping and replacing with the exact SAME permissions they had before (at least with the ACLs) works.


 

So the issue I see at this point is that sometimes the permissions are being ignored, and the users see erroneous error messages about not having proper permissions to affect files. This happens on the clients despite verifying that the permissions are set correctly as I have outlined them above. If I connect from a 10.8.5 based Mac, then everything works fine. This was also the case when the server and the whole network was using 10.8.5. We never had permission issues.


The other wrinkle in this sad saga is that I can revert a client access to AFP instead of SMB it works flawlessly. Today, I had this exact issue happen. Two users were having the "you don't have permissions" error removing a folder one of them created on a share mounted as SMB, despite the permissions being set correctly, and I logged into the same share on one of the two user Macs as AFP and effortlessly removed the folder without any errors (while still mounted as SMB).

 

This kind of buggy crap with Apple's implementation of SMB is legendary enough that SMBUp is becoming a credible (but somewhat awkward) solution to the issue. I wish Apple would just fix whatever is causing their implementation to fail at properly reading permissions. 

http://www.tweaking4all.com/os-tips-and-tricks/macosx-tips-and-tricks/smbup-mac- os-x-smb-fix/o

 

Just to cover one other point. I have tried using a El Crapitan server at another customer with the same results, so "upgrading" is not going to fix the problem reliably enogh for me in this case. I just really hope that Sierra has fixed many of the client side and server bugs in "MacOS" (it is going to take a while for me to get used to not typing "OS X"). This is getting ridiculous.

 

If anyone has anything to suggest or add to the conversation, I am very open to hear what you have to say. My next stop is to call Apple Support. Wish me luck, I am going to need it.

 

I have a customer with a Yosemite 10.10.5 server (running on a 4,1 Mac Pro with a RAID system) and a whole office full of 10.10.5 clients mixed with 5 newer El Crapitan clients (which is extremely buggy, but I digress). Everyone is connecting to the server via SMB and using a number of shares that using POSIX and ACLs for permissions. I have the shares using the local administrator of the server as the owner and the company's named staff group (which I created) as the POSIX group. For permissions I have set the POSIX to 770, with the "everyone" bit set to no access. I have corresponding ACLs for the same admin user and the named staff group set to read and write. I have set the permissions to propagate to all of the child folders and files. When users create a new file or folder they have a default umask of 022, and the ACLs are set correctly, but some times other clients cannot modify the files or delete them. They always have "custom access" when viewed from the Get Info panel on the local computer. Nothing a local user does ever works. It seems that the clients are ignoring the ACLs and relying solely on POSIX in these cases. If I try to fix it on the server end by modifying the permissions, that will sometimes allow the clients to them modify or delete the files, but in many cases, only a restart of the client computer will clear the problem, and in some cases, I have to move or delete the file on the server end.

 

While this behavior is WAY more common on the El Crapitan clients, it does also happen on Yosemite. What I do to mitigate this nightmare is to strip the ACLs from the shares and all child folders about twice a month and then set the posix permissions to 777 in Terminal and then I go back to the Server App and set things up as 775 again and then add in my ACL's and then finally propagate. This tends allow most things to function normally for a time, but I eventually get a few complaints here and there until the problem becomes very common again and I am back to the reset route.

 

So the issue I see at this point is that sometimes the permissions are being ignored and erroneous error messages about not having proper permissions to affect appear on the clients despite verifying that the permissions are set correctly as I have outlined them above. If I connect from a 10.8.5 based Mac, then everything works fine. This was also the case when the server and the whole network was 10.8.5. We never had permission issues.


The other wrinkle in this sad saga is that I can revert a client access to AFP instead of SMB and it works flawlessly. Today, I had this exact issue happen. Two users were having the "you don't have permissions" error removing a folder one of them created on a share mounted as SMB despite the permissions being set correctly, and I logged into the same share on one of the two user Macs as AFP and effortlessly removed the folder without any errors.

 

This kind of buggy crap with Apple's implementation of SMB are legendary enough that SMBUp is becoming a credible (but somewhat awkward) solution to the issue. I wish Apple would just fix whatever is causing their implementation to fail at properly reading permissions. 

http://www.tweaking4all.com/os-tips-and-tricks/macosx-tips-and-tricks/smbup-mac- os-x-smb-fix/o

 

Just to cover one other point. I have tried using a El Crapitan server at another customer with the same results, so "upgrading" is not going to fix it for me in this case. I just really hope that Sierra has fixed many of the client side and server bugs in "MacOS" (it is going to take a while for me to get used to not typing "OS X"). This is getting ridiculous.

 

If anyone has anything to suggest or add to the conversation, I am very open to hear what you have to say. My next stop is to call Apple Support. Wish me luck, I am going to need it.

Posted on Sep 9, 2016 2:00 PM