OS X 10.10 - Shared File is not sharable. ACL & Permissions Question

Your advice gave me a great start. Certain things worked for me, and then other things did not, and I realize after much more testing that the root of my problem is not the ACL list as much as it is the fact that the users are not logged into network accounts. The nearest I can figure is this:

The remote user is working on a personal machine with a personal and local account, which we will call "local_jsmith" for this example. The user connects via SMB using a network account's credentials ("network_jsmith") to access the shared files. We thought that the ACL would grant permissions solely based on the network login; it seemed natural that any user presenting credentials for "network_jsmith" should have and use the permissions associated with this access; in essence, we thought that these credentials would act like an interface wrapper so that "network_jsmith" had the same permissions no matter which computer or user account was being used. So, if J Smith was using Sam's computer which was currently logged in as "sjohn", or if he was using Mary's computer and logged in as "mcartwright", or if he was logged into his own computer as "local_jsmith", his SMB connection to the file server as "network_jsmith" would allow him the same access and privileges at all systems. This is not the case.

It seems that when "network_jsmith" accesses a file, it is transferred to the local machine and opened not as "network_jsmith" but as the local user. When J Smith accesses the files from his personal account, he retrieves them as "network_jsmith", but he handles them as "local_jsmith". Since the remote computer has no knowledge of "local_jsmith" and thus no ability to have ACL's for "local_jsmith", the files are opened in a locked state and cannot be editted by the users.

Now the question remains, is there any way to set up an ACL using a GUID or other identifier that would allow rules to be set up for "local_jsmith"?

There must be some other difference then. To demonstrate the issue in the same way as yourself, I have disconnected from the server named "FileStorage", to which I had connected through Finder by clicking the button "Connect As...". Instead, I will connect now via Finder -> Go -> Connect To Server. I will use the credentials for jaredclemence to connect, although I will continue to use the local account jrc on the client machine. Furthermore, I will use Terminal to access the files and not Finder so that I can view the ACL permissions and take appropriate screen shots.

From an SSH connection in which I am connected as the administrator, I will first document the folders and ACLs for the folder located at Shared/Patient\ Archives/A.

From the SSH connection:

From the SSH connection as server4admin, I will create a new file in the folder shown above and demonstrate the file access permissions:

Now, I connect to the FileServer (smb:\\192.168.76.23) using Finder->Go->Connect To Server:

The terminal shows the following change in the /Volumes folder as seen from the local user jrc:

Now, I will navigate to the Shared folder with the file I have just created named "testing.txt" and view my permissions as seen from the client:

The client sees the owner of this file as jrc:staff (actually, the ownership of all files is seen as jrc:staff from the client, but I cannot show all the files as the file names contain Protected Health Information). The client also sees no ACL.

Switching back to my SSH connection, I see that the owner is still as originally set and that "jaredclemence" still has ACL rights:

When I edit the "testing.txt" file using VI, I get success with the error that the backup file cannot be deleted:

The changes are viewable from the server:

When I attempt to edit the file outside the terminal using OS X Applications selected by the Finder, I receive the following message:

Thank you, Alberto Ravasio,This exercise has helped me find the answer: In order to give a user the ability to edit a file in a directory, one must give that user the "add_file,add_subdirectory,delete_child" permissions. Mac OS X must attempt the creation of a temporary file and the subsequent deletion of the temporary file when determining if a file is "Locked". In the case of simple files like txt documents, the add_file and delete_child permissions are used. In the case of more complex files like Pages and Numbers, the add_subdirectory and delete_child permissions are used; these complex formats use a temporary directory instead of just a temporary file.

I have achieved the results I desire:

• Users are able to access files from any system using network credentials to edit files.
• Users are able to make changes to files after other users from the same groups make edits.
• The user login on the client is irrelevant to the credential decision at the server.

To achieve this result, I did the following:

1. I gave ownership of all files and directories to root:wheel
2. I set POSIX permissions to 0700 for all files and directories.
3. I cleared all existing and erroneous ACL permissions by using the command:

   sudo chmod -R -N ./PatientManagmentDataFolder

4. I added read permissions to the necessary folders and files recursively using the command:

   sudo chmod -R +ai "group:clinic_staff allow list,search,read,execute,file_inherit,directory_inherit" ./PatientManagmentDataFolder

5. I added edit permissions to the folder for the group that has write permissions using the command:

   sudo chmod -R +ai "group:patient_manager_file_editor allow write,append,execute,delete,add_file,add_subdirectory,delete_child,file_inherit ,directory_inherit" ./PatientManagementDataFolder

After performing these steps, I approached several members of the staff and asked them to edit the spreadsheets contained within the folder. The attempts failed or succeeded based on the user's membership to each of the groups defined in the ACL.