Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

SMB and ACLs still not fixed with Yosemite

Hello!


I hoped that the buggy smbd from 10.7 to 10.9 would be fixed with 10.10, but I just stumbled over a new bug. Looks like smbd still ignores ACLs or doing something I do not understand with ACLs and Windows clients.


This is what I found out a few minutes ago - customer has trouble accessing file with the Windows computers from a share for weeks now.

The server is a 10.10.1 with a share configured with ACLs and POSIX rights but when a Windows program is started that has its data files at that share it throws lots of errors with "can not access file XYZ". The program has a button to retry and this never worked - until today.


Today my customer called again and I looked at the troubled file named "AUFNAHME.DBT". This is what was setup:

ls -le AUFNAHME.DBT

-rwxrwxrwx+ 1 root mitarbeiterderpraxis 46018816 10 Dez 14:08 AUFNAHME.DBT

0: user:_spotlight inherited allow read,execute

1: group:kfomitarbeiter inherited allow read,write,execute,delete,append,readattr,writeattr,readextattr,writeextattr,re adsecurity,writesecurity,chown

2: user:kfogruppe inherited allow read,write,execute,delete,append,readattr,writeattr,readextattr,writeextattr,re adsecurity,writesecurity,chown

3: user:kforaum inherited allow read,write,execute,delete,append,readattr,writeattr,readextattr,writeextattr,re adsecurity,writesecurity,chown


The Windows clients login with the name "kforaum"(ACL item 3) - as every one can see you can not get more access rights!

For curiosity I removed the ACL from the file and click retry at the windows program - it worked immediately!


So to me this still looks like a bug within the smbd. I had a horrible time with Mavericks server and Windows file sharing the last year. Because of this I setup a test server with Yosemite and tested smb with a different Windows program - with Mavericks server the program crashed after about 20 minutes of idle time. This bug was fixed with Yosemite.


I setup smb with ACLs enabled.


sudo serveradmin settings smb

Password:

smb:ServerDescription = "Server2"

smb:VirtualAdminShares = no

smb:EnabledServices = _empty_array

smb:NetBIOSName = "server2"

smb:AclsEnabled = yes

smb:AllowGuestAccess = yes

smb:LocalKerberosRealm = "LKDC:SHA1.246365D8C9CAB4635A83105F48BAF65CA14FF831"

smb:wins server:_array_index:0 = _empty_dictionary

smb:DOSCodePage = "437"


If anyone has the same problem, write a bug report for Apple.

If you have a solution or workaround - post it here.


Bye, thanks,

Christoph

Mac mini, OS X Server

Posted on Dec 11, 2014 1:39 AM

Reply
Question marked as Best reply

Posted on Jul 29, 2015 5:41 PM

Did you ever solve this problem Christoph?


We have the same problem, but it appears that it is the Windows users that cause it. From what I can see, when Windows users change or add files, the permissions get set incorrectly (seems to ignore the ACL inherit permissions). So later, other users (Mac and Windows) lose access.


It doesn't seem to have the problem with Mac clients. Fortunately we have only a couple of Windows users, but it is a pain to have to keep propagating permissions from the root to fix the errors.

4 replies
Question marked as Best reply

Jul 29, 2015 5:41 PM in response to Christoph Ewering1

Did you ever solve this problem Christoph?


We have the same problem, but it appears that it is the Windows users that cause it. From what I can see, when Windows users change or add files, the permissions get set incorrectly (seems to ignore the ACL inherit permissions). So later, other users (Mac and Windows) lose access.


It doesn't seem to have the problem with Mac clients. Fortunately we have only a couple of Windows users, but it is a pain to have to keep propagating permissions from the root to fix the errors.

Feb 9, 2016 2:50 PM in response to brycesteiner

Hello!


As brycesteiner wrote I also setup cron jobs running every night to reset ACLs and POSIX rights. It is still a nightmare with OS X server and ACLs - they do work at random.

And the problem is still not fixed in El Capitan - users can not save Word or Excel files they just opened - even though the ACL and POSIX rights allow everything for everybody some user can access files some don't. It is getting worse when uptime of server increases.


Now to the problem with the Windows clients setting the wrong rights - the server has to force the access rights as setup and should not take care how a client would like to have the access rights setup. That what a server is good for.


I think the randomness of ACLs is less a problem with El Capitan but it is still impossible to setup complex ACLs hierarchies.


OS X 10.6.8 was the last Mac OS that was useful for business - every OS after that has horrible bugs within file sharing.


Since at least 10.9.2 is keychain for network home broken and it is still not fixed with 10.11.3 - Apple doesn' care. 😢


Bye

Feb 9, 2016 3:59 PM in response to Christoph Ewering1

What's funny is I didn't have this issue until the update. Even then it wasn't bad until today. Users could create folders and files and everyone could access them.


Today one user was complaining that a couple of folders that had the files deleted couldn't be removed itself. I then went to the server and checked saw the permissions were different and not inheriting like it was supposed to. I reset the ACL and turned file sharing on and off then all heck broke loose. All of the folders and files that were being saved were having this issue, not just the two that started with 10.11.3 update.


My solution to get me through today is to "ignore ownership" in finder. I don't want to leave it that way because it allows people to access places they really shouldn't. Not that I think they would, but I still need to keep things secure.


I guess I do need to file a bug report. I thought it was just me.

SMB and ACLs still not fixed with Yosemite

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.