We just got a new iMac are using the /Users/Shared directory to store media assets (pictures, audio, video) that we want accessible to all users on the machine. After copying over all the files initially, we set the desired permissions and then applied the same permissions to all directory contents recursively. This is working fine, except then whenever someone creates a new file or directory, it does not have the same permissions and we have to repeat the whole permissions process before everyone can access it.

Is there a way that we can set permissions for all new files/directories created within that directory?

  • Extended Attributes will allow you to set some very liberal access permissions, and tell them to propagate inside the directory, and continue to do so on new creations, but for the life of me I can't find instructions. I can only do it on OSX Servers using the Server Admin Tools, which I assume is not a viable option here? Dec 30, 2010 at 2:23
  • Nope. We only have access to the OS discs that came with the iMac. Dec 30, 2010 at 2:33
  • 1
    If you're happy working in the Terminal this may be the answer you're looking for.
    – boehj
    May 26, 2011 at 11:42

2 Answers 2


You can't do this with traditional POSIX-style permissions, but you can with inheritable access control entries. To allow read+write access for the entire "staff" group to everything in /Users/Shared/reallyshared, you'd use:

sudo chmod -R +a "staff allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,file_inherit,directory_inherit" /Users/Shared/reallyshared

The file_inherit,directory_inherit part means that this access control entry will automatically be added to new files & folders created inside this folder, but it doesn't automatically apply to items already there (that's why I added the -R flag to chmod -- that applies it to everything currently within the folder), and it won't be applied to items created somewhere else and then moved into this folder (I don't know of a way around this, sorry).

  • 1
    I would really love to find a way to have this work even for files that are moved into a shared directory. It is frustrating to have files in a shared directory that end up not truly being fully shared.
    – radven
    Nov 4, 2012 at 5:49
  • This still doesn't allow a folder to be written to if the posix permissions don't allow it. Ie I create this folder in Finder: drwxr-xr-x+ 2 User staff 68 Dec 15 14:10 untitled folder The + at the end means it's got the extended ACL applied using your command above, but Windows still says permission denied if I try to write a file to this folder. Only chmod g+w untitled\ folder lets me write to it. Might be because I installed Samba to work around OSX's horrible new SMB implementation. Dec 15, 2014 at 22:14
  • @ChrisDragon: that sounds like samba is not properly respecting the ACL. I found a suggestion here to add nt acl support = no to the [Global] section of /etc/smb.conf, but I'm not sure that's still relevant in currentish versions of samba. Dec 15, 2014 at 22:42

Another approach is to use Terminal (a.k.a shell or command prompt) to create/edit (must be performed as super-user, see sudo) the file:
adding the line:
umask 000
save and reboot. New files/folders (including files changed by save as) will allow everyone read/write.

This works by changing the default file creation permissions for programs, whereas the ACL approach works in terms of access rules bound to particular files and folders.

Without this tweak, files are created allowing user: read-write, group & other: read-only.

If you are sharing between multiple computers, you need to do this for all computers that will use the share.

If you have existing files and folder in the shared area, you need to make them all readable/writable by everyone using:
sudo chmod -R og+w <shared-folder-name>

The command reads in English as change mode, recursive through all sub folders and files, other & group permissions add write access, starting at folder with .

This approach is mentioned in forums to work with at least as early as 10.6 and still works on 10.7.

Other factors still affect access to content. For example, permissions set in the Sharing control panel, home folder permissions/ACLs, and when using Terminal any umask in effect for the shell.

Look up umask and Posix file permissions for details on these Unix concepts. In the write ups, the word directory is Unix parlance synonymous with folder. You will also encounter the terms UID and GID: user and group IDs, which define the Posix ownership of running programs (processes). Note that UIDs and GIDs are numbers which may be the same or different for a given user name across different computers. These numbers are assigned to names in the order accounts are created on a given computer, typically starting with ID 501. Home networks lack a mechanism to harmonize these assignments across computers. Therefore on network shares a file may appear to belong to different users because the user ID to user name binding is determined from the perspective of computer is accessing the file. So shares really always allows everyone to access files to various degrees of everyone. In other words, the Posix "other" permission is an indefinite limit on access ranging from allowing a quite predictable but apparently uncertain degree of access depending on the user IDs assigned on different computers. This leads to apparently absurd variations in experiences, where on some networks, for example a setup with only one user account ever created on each Mac, will be able to share without any permissions tweaks because all accounts will have the same UID (501, no matter what the accounts are named) whereas another network using multiple user accounts per Mac will see problems right away. So some groups will never struggle with this, whereas some others may see problems that develop over time, or problems which appear/disappear spontaneously, depending on when/how additional user accounts are created/used with the shared folder.

It's a mystery why Apple has left such a festering usability defect in the configuration of such an otherwise easy to enable file sharing capability.

On external disks, this problem is addressed with the "Ignore permissions on this volume" option. There may be a similar feature for apple file sharing, but where is it.

If you roll you own Samba service config there are other mechanisms for handling these problems, but Samba is not at all easy to use.

  • 1
    /etc/launchd-user.conf is deprecated in favor of using launchctl. See support.apple.com/en-us/HT201684 Jun 11, 2016 at 17:19
  • 1
    @JessBowers thanks - so I guess sudo launchctl config user umask 000 is what's needed now.
    – mwfearnley
    Feb 27, 2020 at 16:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .