macOS Mojave with server 5.7.1file sharing Group permissions problem :-(

Hey guys I found this related information from high sierra server that helped me and it appears to work for keeping inherited permissions.

Firstly enable ACL permissions for SMB shares with the following command.

Sharing modification via terminal to engage ACLs

sudo defaults write /Library/Preferences/SystemConfiguration/com.apple.smb.server AclsEnabled -bool YES

Then set up inheritance permissions on the parent holder with the following command. This should recursively go through your share and apply the relevant permissions.

sudo chmod -R +a "group:REPLACE_WITH_YOURGROUP_NAME:allow readattr,writeattr,readextattr,writeextattr,readsecurity,list,search,add_file,add_subdirectory,delete_child,file_inherit,directory_inherit" REPLACE_WITH_PATH_TO_PARENT_SHARED_FOLDER

Hey Mark, run the first terminal command only once, but the second command you need to repeat for each group you want to maintain inherited permissions. So if you have Workgroup and Designgroup, You need to run

sudo chmod -R +a "group:Workgroup:allow readattr,writeattr,readextattr,writeextattr,readsecurity,list,search,add_file,add_subdirectory,delete_child,file_inherit,directory_inherit" REPLACE_WITH_PATH_TO_PARENT_SHARED_FOLDER

then

sudo chmod -R +a "group:Designgroup:allow readattr,writeattr,readextattr,writeextattr,readsecurity,list,search,add_file,add_subdirectory,delete_child,file_inherit,directory_inherit" REPLACE_WITH_PATH_TO_PARENT_SHARED_FOLDER

Then both groups with have read write privileges that will be inherited by any file added or modified within the folder of choice. I recommend having these folders at the root of your share drive, so that the permissions aren't nested inside another folder with its own permissions.

YES! It worked! The formatting was maintained and the example shows up perfectly! Here it is again:

So here's my example with the group called designers and a directory on an external RAID called Current Jobs. This is all one line:

sudo chmod -R +a "group:designers allow readattr,writeattr,readextattr,writeextattr,readsecurity,list,search,add_file,add_subdirectory,delete_child,file_inherit,directory_inherit" /Volumes/Promise\ Pegasus/Current\ Jobs

As a note to those who were trying to help but whose syntax was corrupted, I highlited my command text and clicked the button <> at the bottom of the edit pane. Apparently, that's how you format a Unix command.

man chmod, and search for “inherit”.

Beyond the command line or a tool such as Dash.app, Apple’s man page documentation web pages and doc search engine are seemingly incommunicado, but there are copies elsewhere:

https://ss64.com/osx/chmod.html

Search further afield for examples of the file_inherit and directory_inherit acces control list entries.

https://apple.stackexchange.com/questions/31438/how-do-i-use-chmod-on-a-mac-to-m ake-new-files-inherit-parent-directory-permissio

https://apple.stackexchange.com/questions/117601/use-apples-server-admin-tools-t o-force-inherit-permissions

Reading through this, it looks like the command line suggestions are very tricky. I manage many macOS file server, many in mixed Windows/macOS environments. After Server 5.4 dropped, we searched around quite a bit to find something that would work long term for our clients.

So far, the file sharing post-5.4 seems to work fine, except for ACLs. The default inheritance functionality makes file sharing useless for any more than one user.

We have had success with using TinkerTools System 6 for fixing that ACL inheritance issue.

https://www.bresink.com/osx/TinkerToolSys6.html

There are a ton of other features of this program that I am sure sysadmins will appreciate. (I am not associated with TinkerTool, lol).

On a side note, I just checked to see which Samba version Windows 10 uses to communicate with a 10.14 share, and it seems to be 3.0.2 (vs 3.0 in 10.12). This tells me that Apple is doing *some* software dev on file sharing, at least for now, even though it was basically broken after 5.4.

I had this problem myself and opened a ticket with Apple. It was escalated to Enterprise Support. Scenario was SMB Shares with OpenDirectory accounts connecting from non domain-bound Macs. Local accounts could connect to the shares no problem. No OD accounts would connect. After demonstrating the issue forwards and backwards, they had me run the Enterprise Data Collector after elevating debug logging. I replicated the issue and the Data Collector created a dmg of logs that I uploaded.

The issue was that SMB authentication was not available for authentication from OD accounts. Here are the steps:

1. Open Directory Utility.app.
2. Unlock.
3. Select Directory Editor.
4. From 'in node', select LDAPv3.
5. From 'Viewing', select Config.
6. On the left side, select dirserv.
7. Select the padlock next to 'in node' and authenticate with the Directory Administrator account.
8. On the right side, expand the attribute, 'dsAttrTypeNative:apple-enabled-auth-mech'
9. Click the plus next to WEBDAV-DIGEST to add another value.
10. Make the value 'SMB-NTLMv2'.
11. Click Save.
12. Restart.

Confirmed OD accounts could connect via SMB to the server where it could not prior. Apple said the authentication mechanism was removed in the latest version of Mojave (10.14.3). They didn't know if it would be put back in under the next update or not.

When working with ACLs, did you try "Make Inherited Entries Explicit" in the Operations drop down? Did you then Apply and propagate permissions? Did you also check the extra two boxes under Inheritance that are not checked by default (and Apply/propagate)?

I have had to perform a similar downgrade, Server version 5.3.1 I think is the last version that will work properly. I backed up erased, installed Mac OS Sierra and then found Server 5.3.1 in my purchase history and re-installed, Back to having a working file server until a fix has been announced.

Hey Guys. I think I figured out a problem with this discussion. Apple's comment tool is changing the syntax and dropping part of the end of an argument because I'm not very experienced with it, so everyone is trying to copy and paste but they're missing parts so the command fails. I'm trying to figure out the formatting into showing it correctly. THERE ARE NO CARRIAGE RETURNS IN THIS COMMAND:

sudo chmod -R +a "group:YourGroupHere allow readattr,writeattr,readextattr,writeextattr,readsecurity,list,search,add_file,add_subdirectory,delete_child,file_inherit,directory_inherit" /path/to/shared/folder

I'll dissect the command here:

sudo <- which means to run the chmod as root - this is what makes it prompt you for an admin password

chmod <- this is the main command for changing file permissions in a unix environment

-R <- this is an argument for the chmod command that tells it to effect files recursively through subfolders

+a <- I believe this effectively tells chmod to include ACLs too (this is an oversimplification)

" <- quote marks surround the entire set of "settings" that you want chmod to apply to each file and folder

group:MyGroupName <- is the group you're granting permissions for, formatted properly for chmod

allow <- you want to grant the group the following permissions for each file and folder (as opposed to deny)

readattr through directory_inherit <- these are all the specific permissions you want to grant. No spaces, spelling is important

" <- close the quote, then a space, then

/path/to/shared/folder <- this is the directory you want to apply the settings to.

NOTE that most of the problems I've seen in replies are syntax errors caused by the helpful posters' comments being manipulated. Sorry about that, but it won't let me go back and edit. :( Quote marks are important. Spaces are important. LACK of spaces are important. Unfortunately, this forum doesn't seem to allow me to paste a command as a single line.

There is NOT a carriage return after the word "allow" but there is a space. There is also a space after the last quote mark.

Any spaces in the directory path MUST be represented by a backslash and a space. In unix, spaces separate lots of things like commands and arguments. If you leave the space, the unix command will believe that the path ends at the space. The backslash means "take the next character as a character at face value." So in this example, we humans see the path as

/Volumes/Promise Pegasus/Current Jobs

BUT it must be formatted unix friendly so we use

/Volumes/Promise\ Pegasus/Current\ Jobs

So here's my example with the group called designers and a directory called Current Jobs. This is all one line.

sudo chmod -R +a "group:designers allow readattr,writeattr,readextattr,writeextattr,readsecurity,list,search,add_file,add_subdirectory,delete_child,file_inherit,directory_inherit" /Volumes/Promise\ Pegasus/Current\ Jobs

I hope this helps. And thanks again Benny2g for the real work!

Were you able to get the permissions and inheritance fixed using command line or TinkerTool?

Are these issues seemingly random?

If yes to both of the above, then you may be having the exact same problem I had. After hours of testing and reapplying permissions, we just went back to AFP for a 10.14 file server. That totally fixed the issue. We were starting to deploy all servers running SMB only, and only ran into this issue once. Try making the share AFP-only and see if that fixes it.

I wonder if the real issue is which way the disk that's being shared is formatted - APFS vs HFS+. If the folder you are sharing lives on an external drive, you have the choice of how to format that drive. But if it lives on your boot drive, you are forced to stick with HFS+.

try moving your shared folder to an external HFS+ volume and share it from there. Please post the results - a lot of us are struggling with this.

thank.

I had problems executing your great suggestion - bash on my install of Mojave didn't seem to like the way you used spaces. So I'm posting a correction for those who must experiment but aren't command line users. You must supply your own MyGroupName and your own /path/to/shared/folder:

sudo chmod -R +a "group:MyGroupName allow readattr,writeattr,readextattr,writeextattr,readsecurity,list,search,add_file,add_subdirectory,delete_child,file_inherit,directory_inherit" /path/to/shared/folder

Wow. Just had this happen to me with my first client moving to a new Mac Mini on OS X 10.14.4.

Noticed some folders permissions were wrong or locking users out. took awhile to figure out how badly Apple stripped the Server app.

I eventually tried using the Get Info window on the shared folders and adjusting permissions there. I then tried the "Gear" button and clicked on "Apply to enclosed items...". As soon as I saw the progress bar pop up and disappear in less than a second, I knew it didn't work. After multiple attempts I called Apple Support. After explaining and then bumped up in support, then waiting for that person to confer with others, they had the audacity to say,

"That is expected behavior, you need to change the permissions on each folder."

I said, really, all 10,000 folders? Yes was the answer. I hung up at that point and started on the command line solution. Found it last night and then found this today.

I did run the command line last night and so far all the users today have had no issues.

Will have to get Tinkertool and play with that to see if it has any advantages.

Thanks to all of you for banging on this issue. I just cannot wrap my head around the fact that Apple is just letting Server die on the vine.

Has anyone found a better Server that support SMB and AFP? I assume AFP is needed for the Search to work and index files.

Not to mention more reliable file saves, naming and all the other SMB issues.

@MarkDannau:

You might have already checked this, but you have to specify AFP for each share in System Preferences > Sharing (select share) then click Options.

And I've seen that check come unchecked unintentionally more than once. I want to say it might have been an update that did it to me, but I can't be sure.

And hopefully you already know that you CANNOT share a folder using AFP if the folder is sitting on an APFS disk. Apple does not allow it.

Most of what Server.app had provided is deprecated and now gone, or has been migrated into the base macOS system and tools.

This particular file-sharing feature migrated into macOS with High Sierra.

Here, migrating to a NAS box might be an option, depending on local requirements and considerations.

Prepare for changes to macOS Server 5.7.1 - Apple Support

https://developer.apple.com/support/macos-server/macOS-Server-Service-Migration- Guide.pdf