App Mac Server: gli utenti di rete dispongono delle autorizzazioni appropriate ma i gruppi di rete non sono in grado di apportare modifiche ai file

Da link

"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."

Ci sono due cose qui in gioco, permessi di stile POSIX (basati su * nix) e ACL NFSv4 (Access Control List) usati sul tuo server.

Li hai impostati su AFP dopo i problemi in corso con SMB. Le cose sembrano diventare pelose quando si usa AFP e Apple ha cambiato moltissimo SMB dopo aver rotto i legami con SAMBA e implementato la propria versione, anche se minore, di SMB (tu Mac geek là fuori, correggimi se sbaglio - voglio sapere. ..)

Da un articolo su TechRepublic Ho trovato questa grande spiegazione:

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.

E se ciò non bastasse, qui contiene alcune informazioni approfondite sulla condivisione, inclusa la condivisione e la visualizzazione delle condivisioni dal terminale.