Mac Server app: Network users have proper permissions but Network Groups are unable to make changes to files

Solution 1:

From https://discussions.apple.com/thread/3288643

"So here is what I did wrong. I changed the default group that was already set for the share point. It is however IMPORTANT to ADD a new group or user if you want to keep the inheritance. As far as I know the default permissions are only responsible for posix and not for ACL. Be sure to add this new group on top of the others and then propagate the permissions."

There are two things in play here, POSIX style permissions (*nix based) and NFSv4 ACLs (Access Control Lists) used on your server.

You set them to AFP after ongoing issues using SMB. Things seem to get hairy when using AFP and Apple changed up SMB a lot after breaking ties with SAMBA and implementing their own, albeit lesser version of SMB (you Mac geeks out there, correct me if I'm wrong - I want to know...)

From an article on TechRepublic I found this great explanation:

Most UNIX systems use the standard POSIX (Portable Operating System Interface) permissions when managing access to files. Standard POSIX permissions are independent of which file system they are used on (provided the system supports them), and anyone familiar with Linux or UNIX will be familiar with them as they are the standard way to set very basic access control on files and directories.

Essentially, you can define the owner of a file or directory, the group that owns it, and "other" (everyone who is not the owning user or a member of the owning group). You can further define whether or not each of these has read, write, or execute permission to the file or directory. With a file, these permissions mean that the user can read the file, write to it, change or delete it, or execute it as a program. For directories, these permissions mean that the user can read the contents of a directory (but not necessarily the contents of the files in the directory), can write to the directory (create and delete files), or execute (allows the user to traverse that directory tree in order to access files or subdirectories, although it does not on its own allow permission to see the contents of the directory).

Most operating systems also support some form of Access Control Lists (or ACLs). Often times this is also dependent upon which filesystem is in use, or which implementation can be used on which file system (the two primary ACL types are POSIX.1e ACLs and NFSv4 ACLs). Mac OS X is no different and, as of OS X 10.4, it has supported NFSv4 ACLs when used with the HFS+ file system. Using these ACLs on OS X are quite simple; you may even be using them without knowing it.

ACLs are made up of ACEs (Access Control Entries) and each ACL can contain more than one ACE. ACLs provide a lot more flexibility and fine-grained control over permissions of files and directories than standard POSIX permissions. For instance, some of the capabilities that ACLs provide for files include read, write, execute, and append permissions (append only allows you to add to an existing file, not change existing contents or remove it). Some capabilities for directories include listing entries, searching entries, adding a file, adding a sub-directory, or deleting contents. Another nice feature of ACLs is called "inheritance," where you can set an inheritance permission so that a directory's file contents can inherit one set of ACLs, while directories inherit another set.

As you can see, ACLs are very powerful. For instance, if you had a directory that contained developer manuals, you might make the directory writable to developers and read-only to sales people. You might also want to give interns access to some of the files, but you don't want to make them a part of the developer or sales group because those two groups have access to too many other files. In this scenario, you might make the directory owned by one particular user, or the root (administrator) user, and group-owned by the "developers" group, with the files and directories writable by both the owner and group. You would then use ACLs to apply read-only permissions to certain files for the "sales" group, and could also use ACLs to apply read-only access to the explicit users that are interns (as opposed to creating a new group for interns). With standard POSIX permissions, this would not be easily possible.

If you have used the Finder Get Info command on a file or directory, most likely you have noticed the Sharing & Permissions pane at the bottom. By default, it shows the standard POSIX permissions entries:

These permissions, on the command line, would equate to an ownership of "vdanen:staff" and mode 0750 (or 0640 if this were a file). This can be seen on the command line as:

drwxr-xr-x 2 vdanen staff 68 Mar 11 22:30 New

To add ACLs to this directory, you can either use the chown and chmod commands, or the Finder. Using chown/chmod gives a lot more flexibility as the Finder limits you quite a bit and makes certain assumptions for you. For instance, to give access to this directory to members of the admin group as Read Only, you would click the + button in the Sharing & Permissions pane, select the user or group, and then set the appropriate privilege:

Now the members of the admin group have read-only access to this folder. Not very difficult to set in the Finder, is it? We can also observe the ACLs on the command line, using the -le switch to the ls command:

% /bin/ls -le total 288 drwxr-xr-x+ 2 vdanen staff 68 Mar 11 22:30 New 0: group:admin allow list,search,readattr,readextattr,readsecurity

The Finder gave more permissions than just the "list" or "search" permissions; it also allows the admin group to read extended attributes and ACLs.

To accomplish the same on the command line, you would use:

% mkdir New2 % /bin/chmod +a "admin allow read,readattr,readextattr,readsecurity" New2 % /bin/ls -le total 288 drwxr-xr-x+ 2 vdanen staff 68 Mar 11 23:06 New2 0: group:admin allow list,readattr,readextattr,readsecurity % /bin/chmod +a "admin allow search" New2 % /bin/ls -le total 288 drwxr-xr-x+ 2 vdanen staff 68 Mar 11 23:06 New2 0: group:admin allow list,search,readattr,readextattr,readsecurity

As you can see, the initial chmod command missed an ACL; it's easy enough to add a new entry later. And if you need to remove one, that is easy too:

% /bin/chmod -a "admin allow search" New2

The admin group now no longer has search permissions on this directory. You’ll note that in each case, I am specifying an explicit path to the ls and chmod commands. This is because I have Fink installed, and the GNU tools that are installed through Fink do not understand OS X ACLs, and these commands will not work with them (the default PATH on the system puts /sw/bin before /bin/, so when I type "ls", it is "/sw/bin/ls" that is being executed, rather than "/bin/ls").

Mac OS X Server (and, presumably, Lion as well) has a more sophisticated GUI front-end to manipulating ACLs than the Finder, but for most basic tasks, the Finder will suffice. It does not handle inheritance, however, which is a shame. It does allow you to apply the permissions set on a directory to files and directories within it by using the "Apply to enclosed items..." menu entry from the gear pull-down menu, which arguably accomplishes something similar; however, if you change the directory permissions you need to re-apply them, and also if you added new folders or files, etc.

The chmod manpage (”man chmod”) gives a very good explanation of ACLs and how to apply them. ACEs in an ACL do observe order, so you can use chown to specify where a specific ACE needs to be positioned within the ACL, and of course you can get a lot more specific than you could with the Finder.

ACLs on OS X work very similarly to ACLs on other POSIX systems, including Linux. The permissions may differ somewhat, as does the mechanism for implementing and managing them, but the benefits are identical. This ACL support in OS X is also compatible with certain versions of Windows and Windows Server.

And if that isn't enough, here is some really good in-depth information on sharing, including sharing and viewing the shares from Terminal.

Solution 2:

Short Version - for Mojave Use TinkerTool System 6 (Not to be confused with TinkerTool) https://www.bresink.com/osx/TinkerToolSys6.html

Long Version: I was having a similar problem after upgrading from a Mac Mini Server 5,3 running El Capitan running Server 5.1 to a new mac mini server running Mojave and Server 5.8. I couldn't find a good migration path, so I set up all the users and groups again. Permissions were a mess, with long lists of "Fetching" showing up in the Get Info boxes on files and folders, and trouble with users access to files and folders.

After struggling for days, I ditched Server 5.8, and set up Users (Users as Sharing Only) and Groups in the built-in utility (System Preferences:Users and Groups). Then I enabled File Sharing (System Preferences:Sharing:File Sharing checkbox) and assigned Groups to the folders I needed those groups to be able to access. One would think that would resolve the permission problems, but it didn't. Neither did resetting permissions in the Get Info box and applying permissions to all enclosed items. Inheritance was still an issue, and permissions were changing automatically. I was finally able to reset all permissions AND INHERITANCE using TinkerTool System in less than an hour. It would have been possible using command-line, but not nearly as easy, and TinkerTool System is only $14.

2 other tips I picked up.

1. Don't assign "No Access" to the group "Everyone" as this will (or can) supersede other Group permissions. Strangely, assigning "Read Only" to "Everyone" does not supersede other Group permissions.

2. Although I didn't have this problem, it was what Apple support suspected, and side-tracked them for a long time. Keep folders you want to share with a group in the root directory of the drive, and don't nest folders with different group access inside of each other.