Jared Clemence

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

I am running OS X Server on OS X 10.10 (Yosemite). A file is shared among all members of the "is_medical_assistant" group; the folder that contains the file is also owned and shared by this group.  Using the file permission settings of OS X Server, I have given the members of the "is_medical_assistant" group Full Control of both the folder and the file; furthermore, the permissions on the folder are set to inherit to the child files, folders and all descendants.

 

Screen Shot 2016-03-09 at 15.51.27.png

 

The goal is to allow Employee A to edit the file over an SMB share.  Employee B then needs to be able to open the file at a future time and also make edits.

 

The problem is that when Employee A edits and saves the file in Numbers, it saves with new ownership: "Employee A":wheel, and Employee B is no longer able to edit the file. Employee B can open and read the file but cannot edit and save changes.

 

This problem is racking my brain, and I don't know what to do.

 

I have tried the following:

  • using file ownership and group settings (chown) to assign ownership of the file to the group at a POSIX level.
  • using a script run by cron to chown the wheel group to the "is_medical_assistant" group.
  • using chown to set ACL's manually.

 

The cron job fails, presumably, because the administrator account does not have membership to any of the groups that can read or write to the directory, although adding the administrator to the group does not seem to have a positive effect.

 

All help is appreciated!

OS X Server 4, OS X Yosemite (10.10.3)

Posted on Mar 9, 2016 3:57 PM

Close

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

  • All replies
  • Helpful answers

  • by Alberto Ravasio,Helpful

    Alberto Ravasio Alberto Ravasio Mar 14, 2016 11:55 AM in response to Jared Clemence
    Level 5 (4,070 points)
    Mar 14, 2016 11:55 AM in response to Jared Clemence

    This is how I do operate.

     

    The directory MacUser is shared among users of the design group

     

    The POSIX permission are as follows

     

    server:RAID5 adminuser$ ls -laedO MacUser/

    drwxr-xr-x@ 50 root  admin  - 1700  1 Mar 11:18 MacUser/

     

    It is much easier operate on ACLs to grant access to users and groups. It does not matter which is the owner and what POSIX permission the file/directory has because ACLs have priority.

     

    • adminuser is the local server administrator user
    • design is the local network group
    • _spotlight is automatically added by the system

     

    0: user:adminuser allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextat tr,writeextattr,readsecurity,writesecurity,chown,file_inherit,directory_inherit

    1: group:design allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextat tr,writeextattr,readsecurity,writesecurity,chown,file_inherit,directory_inherit

    2: user:_spotlight inherited allow list,search,file_inherit,directory_inherit

  • by Jared Clemence,

    Jared Clemence Jared Clemence Mar 14, 2016 11:55 AM in response to Alberto Ravasio
    Level 1 (40 points)
    Mar 14, 2016 11:55 AM in response to Alberto Ravasio

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

  • by Alberto Ravasio,

    Alberto Ravasio Alberto Ravasio Mar 14, 2016 2:52 PM in response to Jared Clemence
    Level 5 (4,070 points)
    Mar 14, 2016 2:52 PM in response to Jared Clemence

    Jared Clemence wrote:

     

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

     

    Hey Jared.

     

    This is not how it works for me.

     

    I connected to a remote Mac Mini server via VPN using my Mac. I am logged in on my Mac as aravasio.

    In Finder -> Go -> Go to server -> smb://192.168.1.242/NetScan

    I logged into the Mac Mini server as the network account Mac05

     

    This is the result of the mount

     

    //Mac05@192.168.1.242/NetScan on /Volumes/NetScan (smbfs, nodev, nosuid, mounted by aravasio)

     

    I created TextFile.txt  and saved it on /Volumes/NetScan

     

    This is how I see the file locally

    MyMac:~ aravasio$ ls -lae@ /Volumes/NetScan/TextFile.txt

    -rw-r--r--@ 1 aravasio  staff  714 14 Mar 21:57 /Volumes/NetScan/TextFile.txt

      com.apple.FinderInfo 32

      com.apple.TextEncoding 15

     

    BUT, this is the file as seen on the server

     

    server:~ adminuser$ ls -lae /Volumes/RAID5/NetScan/TextFile.txt

    -rw-r--r--@ 1 mac05  admin  2673 14 Mar 21:54 /Volumes/RAID5/NetScan/TextFile.txt

    0: user: adminuser inherited allow read,write,execute,append,readattr,writeattr,readextattr,writeextattr,readsecur ity,writesecurity,chown

    1: user:xerscan inherited allow read,write,execute,append,readattr,writeattr,readextattr,writeextattr,readsecur ity,writesecurity,chown

    2: group:design inherited allow read,write,execute,append,readattr,writeattr,readextattr,writeextattr,readsecur ity,writesecurity,chown

    3: user:_spotlight inherited allow read,execute,readextattr

  • by Jared Clemence,

    Jared Clemence Jared Clemence Mar 14, 2016 3:30 PM in response to Alberto Ravasio
    Level 1 (40 points)
    Mar 14, 2016 3:30 PM in response to Alberto Ravasio

    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:

    Screen Shot 2016-03-14 at 15.05.06.png

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

    Screen Shot 2016-03-14 at 15.07.57.png

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

     

    Screen Shot 2016-03-14 at 15.10.05.png

    Screen Shot 2016-03-14 at 15.10.20.png

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

    Screen Shot 2016-03-14 at 15.10.42.png

    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:

    Screen Shot 2016-03-14 at 15.14.24.png

    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:

    Screen Shot 2016-03-14 at 15.21.24.png

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

    Screen Shot 2016-03-14 at 15.25.15.png

    The changes are viewable from the server:

    Screen Shot 2016-03-14 at 15.25.28.png

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

    Screen Shot 2016-03-14 at 15.29.52.png

  • by Jared Clemence,Solvedanswer

    Jared Clemence Jared Clemence Mar 14, 2016 4:41 PM in response to Jared Clemence
    Level 1 (40 points)
    Mar 14, 2016 4:41 PM in response to Jared Clemence

    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.