All sharing settings (users and folders and permissions) disappeared after macOS update

I've covered this previously here: Files & Folders not inheriting ACL pe… - Apple Community

The issue is that Apple broke the UI for proper permissions application long ago. You must use the command line to properly set file and directory inherit on your parent folder.

Let's create a simple example. You have a folder in /Users/Shared called Data. You want to share the Data folder and apply permissions to allow a group of users to have equal access to all children and descendants within the folder. Ideally, you will be creating a group and adding a group to the permissions table. For example, when initially adding a folder to Sharing, you will see three permissions entries. These are known as the POSIX permissions. From the top down, it is the Owner, Group, and Everyone. Here is an example:

Using the Terminal command to list the contents and the permissions of the /Users/Shared folder:

ls -lae /Users/Shared

we see the same POSIX permissions represented by the drwxr-xr-x.

drwxr-xr-x   2 rbundonis  wheel    64 Aug 10 07:35 Data

This means:

• the item we are looking at is a directory (d)

• the Owner (rbundonis) has Read (r), Write (w), and Execute/Traverse (x) rights (the first set of rwx)

• the Group (wheel) has Read (r) and Execute/Traverse (x) rights (the second set of r-x)

• Everyone has Read (r) and Execute/Traverse (x) rights (the final set of r-x)

You now must add an ACE (access control entry) to build your ACL. In this example, I've used the group called Designers. If you are not using Server.app, the group can be created in System Preferences > Users & Groups. Create the group first, then add users to it. Once your group(s) is/are defined, go to Sharing and add an entry to the permissions table, setting your group as the ACE. Define the permission as Read and Write.

One would think this is all that is needed... Think again. This is where Apple's UI tools have been broken for years. To see what the action above did, run this command from Terminal once again:

ls -lae /Users/Shared

You will now see this result:

drwxr-xr-x+  2 rbundonis  wheel    64 Aug 10 07:35 Data
 0: group:Designers allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity

Note the POSIX permissions have not changed. But you now have an ACE that creates your ACL. Examine the entry. Note that the is no file or directory inheritance in your list of rights. You must add that in. To do that, use this command (replace paths and folder names to match your environment):

chmod =a# 0 "Designers allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,file_inherit,directory_inherit" /Users/Shared/Data

This command sets the ACE # 0 to allow the Designers group to list, add_file, search, .... file_inherit, directory_inherit on the folder /Users/Shared/Data.

Run this command once more to compare the ACE created by System Preferences to the one you modified with the chmod command:

ls -lae /Users/Shared

Now you have the proper ACL set. Quit System Preferences. Launch System Preferences and select Sharing. (the quit and launch are needed as you made changes outside of System Preferences. By quitting and launching, System Preferences rereads the state of the permissions on disk). Right-click on the Data folder and choose Apple Permissions to Enclosed Items.

While the propagation of permissions is happening, the permissions entries will turn gray. Wait until they turn black again. This means the inheritance propagation is complete. Please note, large data sets equal long propagation times. Wait for it.

If you have any clients with the Share mounted, unmount the share. Now mount the share to allow the client to read the new permissions table.

Permissions inheritance is now on and all users will have proper rights to all files and folders.

Hope this is helpful. Don't expect a fix from Apple any time soon. This has been broken since Mojave. Remember, Server is dead.

Reid

Select your external USB drive with the data on it and Get Info on the drive (Command I). Look at the bottom of the Get Info window and reveal the Sharing & Permissions section if it is not visible.

Is the "Ignore ownership on this volume" checked? If so, then the drive will ignore all permissions, both POSIX and ACL, granting everyone access to everything.

Press the Padlock to unlock the panel. Uncheck the Ignore ownership on this volume box. Restart the computer. After the reboot, Get Info on the drive again and confirm that the box remained unchecked.

Reid

By any chance, did you change the permissions on the root of the external disk? Based on your report, you are seeing the following:

• If the Ignore Permissions box is checked for the disk, users have access to the shares, but no permissions are enforced. This is logical as the purpose of Ignore Permissions is to share content without restrictions. The drive, when the box is checked, will ignore both POSIX and ACLs. So, while your users can connect, they have rights to everything. This is the expected behavior when Ignore Permissions is checked.

• If the Ignore Permissions box is unchecked for the disk, users have no access to the shares. I suspect that you have restricted the permissions of the drive (or the shared folder). This will prevent the users from connecting because the users cannot traverse from the root of the drive to get to the shared folder. The user must have access to read and traverse both the drive (Data-2) and all folders leading up to the shared folder. The screen shot of the Finder shows the folder named Fileserver but the screenshot of the Sharing pane shows fælles. Which is your parent shared folder?

Let's explore this.

Open Terminal and type this command to list the permissions of the mounted external drive:

ls -l

You should get a result that looks something like this (in my example, the external drive is titled DataDisk):

drwxrwxr-x  10 rbundonis  staff  408 Aug 10 11:10 DataDisk
lrwxr-xr-x   1 root       wheel    1 Jul 21 19:23 Macintosh HD -> /

Note the permissions in the above result. The physical disk has a permission that allows the owner (rbundonis) to rwx, the POSIX group staff to rwx, and everyone else to r-x. The most important piece here is the x bit on each of the preference domains. Without the x, you cannot traverse.

Using the same examples from previous posts, this allows me to connect to the shared folder using a user in the Designers group.

Ah, but what if you messed with the drives POSIX permissions. For example, let's say that your permissions were:

drwx------  10 rbundonis  staff  408 Aug 10 11:10 DataDisk

Note that the permissions only allow the owner to traverse to the lower levels of the drive. The permissions are very restrictive, allowing the owner (rbundonis) to read, write and traverse, while the staff group and everyone else has no permissions, ---.

Now when trying to connect from a client, I am presented with:

Does that look familiar?

If so, then you will need to correct the permissions on the root of the physical disk while Ignore Permissions is off. To do this, and assuming you have granted Terminal Full Disk Access, run this command:

chmod 775 /Volumes/Data-2

If you are not the owner of the disk, prefix the command with sudo to elevate permissions.

If the disk has the correct permissions, then investigate the Fileserver folder. It too must allow all users to traverse. If the Fileserver folder has restrictive permissions, you will then be stopped there. This also applies to the fælles folder. The file sharing users must be able to read and traverse /Volumes/Data-2/Fileserver/fælles in order to acess the enclosed data. If any of these folders are restricting POSIX read and traverse, then you will end up unable to connect.

Hope this is helpful,

Reid

If you are interested in resetting the permissions on your entire data set, use the following commands to reset the data by removing all ACLs and reseting POSIX permissions to default umask. (Note, if you are storing executable scripts, application bundles, or other files types that rely on the x attribute, the reset to default umask will mess up the file behavior - likewise, if you are setting folders to everyone no access, these will restore access to everyone).

Use these only if you are sure you want to reset the permissions attributes. Based on your comment, you have a complex, single share, with broken inheritance and explicit permissions created within the children and descendants chain. Resetting everything may not be your ideal path. These commands are provided for your investigation and consideration.

In this example, I will assume your drive is named DataDisk and that it contains a shared folder called Data.

To clear all ACLs from your data, run this command:

sudo chmod -R -N /Volumes/DataDisk/Data

To reset all files to standard umask of rw-r--r--, run this command:

sudo find /Volumes/DataDisk/Data -type f -exec chmod 644 {} \;

To reset all folders to standard umaks of rwxr-xr-x, run this command:

sudo find /Volumes/DataDisk/Data -type d -exec chmod 755 {} \;

Remember, this is a public forum. Research and understand what these commands do before you run them. As mentioned, if you have a single share with inherited permissions converted to explicit on subfolders, using the commands above may cause more headaches and a longer reset of your original permissions model.

Also, please consider that if data is to be segregated due to sensitivity, it may make sense to have more than one share. Control access at the share level, not the subfolder level. It is easier to document and enforce at the parent level than to remember all of the changes in the subfolders.

Reid

To first answer your questions.

Which is your parent shared folder?

That is a good question, and I don’t know how to answer it. All the shared folders are within the Filserver folder, so I guess the answer is that Filserver is the parent of all the shared folders.

When sharing a folder, the folder you share is commonly called the parent. The parent then has children and descendants in the form of folders, folders within folders, and files within those folders.. For example, if the parent folder is Filserver, and it contains two folders called In Progress and Complete, they are the children. If In Progress and Complete contain items, they are the descendants of Filserver. Think of it like a family tree (or, more apt, a file system tree). Now, why is this important to understand? If you are trying to provide permissions inheritance, it is much like how families work. The ACL is placed on the parent and the parent passes those traits on to the children and the children on to the descendants. Sort of like genetics. If you want to make sure your users can all have read/write access to files within the descendant's tree, you must ensure that the parent has an ACL that will pass down the tree to those files.

Now, for this to work, you must allow the drive to support permissions (uncheck that Ignore Permissions box), you must set an ACL on the parent folder (POSIX inheritance was removed in 10.5 if memory serves), and the process (SMB in the case of Monterey) and the users must be able to traverse the drive and the folders that exist above the parent folder. Think of these are the forebears. This as illustrated in a previous post. If you want to share a folder named Filserver, and that folder is sitting on a drive called Data-2 and inside a folder called SharedFolders, then the path to FilServer is:

/Volumes/Data-2/SharedFolders/Filserver

Note, you are telling the File Sharing service to share the folder called Filserver. But you must be able to traverse the forebears in order to reach it. If the connecting user or the service does not have POSIX permissions to read and traverse to Filserver, you will get the "There was a problem connecting..." error.

...

Does that look familiar?

That is exactly what I see (except for the IP-address of course)

HOWEVER, I have managed to mess around with it via show info in Finder … enough to make it work a little. Sounds weird, yes? The users can now connect and read their files and edit and save. And some of them can create new folders within the folders, they have access to. But they can NOT save stuff in the new folders they create, so the permissions are clearly not propagated … the new folders do not inherit the permissions of the parent folders. However this is not consistent for all users, so I may have to run "Apply to enclosed items" on all the shared folders one by one - again.

Does this make sense to you? 

Correct on the Apply Permissions to Enclosed Items. Do this from System Preferences > Sharing. Do not trust the Get Info window. And, review the earlier post that details how to add file_inherit and directory_inherit to the parent folder. Again, the UI is broken and the chmod command is required to do this. (pro tip... if your default shell is zsh, the chmod command above will fail. Simply switch shells by typing bash and hitting return.).

The part that does not make a lot of sense is this part "But they can NOT save stuff in the new folders they create." That one is stumping me. Here is why. Let's use your user Adam. If Adam is able to authenticate to the server and navigate to a location and create a folder, at the bare minimum, Adam is the POSIX owner and he should be able to add items to the folder. If inheritance is not set properly, then other users will not be able to add or edit items within the folder Adam created.

The key take away is that you have existing data. That data likely does not have correct inheritance defined. To direct the parent to share its attributes to the children and descendants, you must propagate (Apply Permissions to Enclosed Items).

Ah, but if you do that from Filserver, then the permissions of Filserver will cascade to ALL children and descendants. In your shared folder, you have children who want to behave different than the parent. We will pick on Adam again. I assume, and based on what you've defined, only Adam should have access to Adam's folder. In this case, you must create a break in the family tree.

While Filserver may be set to allow everyone to collaborate on the enclosed items, the Adam folder does not want those genes. Instead, you must break inheritance, converting inherited permissions into explicit and then making Adam a parent within the Filserver family tree. Consider it a rogue branch of the family. By doing this, you can support inheritance where needed and restrictions in other places.

chmod 775 /Volumes/Data-2

This is when it gets scary for me.

What are the risks of doing that?

Could I risk making the disk unreadable? Hopefully not.

Will this command “reset” all permissions on the disk – the POSIX permissions, so everything will go back to how it should be?

And what would be the follow-up to that? Delete all the sharing settings in System Preferences -> Sharing and restart the Mini and then set up sharing again? Or …?

You have already been using Batchmod with limited understanding of the consequences. Here is a rapid primer. POSIX permissions are elegant and effective in their simplicity and limitations. They are from an older, simpler time. But they still must be understood in macOS.

The permissions are based on three components. I've hit on this above. However, here is the expanded view. The three permissions are r w and x and there are three blocks that can be granted rights; the owner, the group, and other. Now, where does 755 come from?

r = 4

w = 2

x = 1

By using this math, any combination of these items will result in a unique sum. If you want a file to be read only for owner, group, and other, then you would use 444. That will produce r--r--r--. If you are creating an executable script and need only the owner to execute but the group and other to read, you would use 744, resulting in rwxr--r--. The sum of 4 + 2 + 1 is 7. The sum of 4 is 4. For one more example, if you want the owner, the group, and other to be able to read and write a file, use 666. The sum of 4 + 2 is 6.

Once again, these permissions should be set when Ignore Permissions on the drive is off. And remember, POSIX does not inherit as macOS will create files and folders based on the operating systems standard umask (that is 755 for folder and 644 for files).

But POSIX has its limits and as mentioned, does not inherit. This is why you need ACLs.

So, to the risks. Permissions are relatively easily changed. And changed again. Permissions are part of metadata, not your data. Altering permissions are reversible. For example, you can use the ls -l command to identify the permissions. Then you can change them. Test. Alter. Test. Repeat until you have it the way you want.

Now, going back to what you have and recommending were to go. What you have:

The green folder = All employees can use this - this is the common share for work

The orange folders = Only a few select people can access these folders. These are finance and stuff.

The red folders = Only the specific person kan access this folder. This is their private space.

There are a few ways to handle this.

You can address each data set as unique. The All Staff (green), Finance (orange), and Users (red). This would allow for easier control of the parent permissions. The All Staff would have a group added to the ACL. The group contains all staff members. The ACL will be customized to properly set file and directory inherit. The Finance folder would also have a group set to an ACL. But it would be a group that only contains the users who are authorized to access the folder. It too would have directory and file inheritance. But this will ensure that unauthorized users cannot access the share. The final folder is the Users folder. This you don't need any ACL since you can rely on restrictive POSIX. That will limit the each user to his or her own folder. This approach keeps each data set isolated.

Or, you can embrace what you have. In this case, the parent folder (Filserver) is really not a parent. It becomes part of the forebears. It is the folders inside Filserver that are the parent folders. Filserver becomes the mount point and no ACL or inheritance is needed at this level. Instead, each of the folders inside Filserver becomes a parent with and ACL and inheritance or with no ACL and restrictive POSIX (the user folders).

Ok, with luck I am conveying this properly. Monterey will work for you. But taking control and understanding the permissions system is key to success.