Home > Mac administration, Mac OS X, macOS > macOS Sierra’s /Volumes folder is no longer world-writable

macOS Sierra’s /Volumes folder is no longer world-writable

One of the changes made in macOS Sierra is summed up by my colleague @n8felton below:

/Volumes is the invisible directory used by OS X and macOS as the OS’s default mount point for accessing the filesystems of other storage (like external hard drives, USB flash drives, mounted disk images, network fileshares, etc.)

Sierra 2016 09 21 at 8 56 48 AM

Up to OS X El Capitan, the /Volumes directory was world-writable and had the following permissions:

Owner: Read, Write, Execute
Group: Read, Write, Execute
Everyone: Read, Write, Execute

view raw


hosted with ❤ by GitHub

ElCap 2016 09 21 at 11 20 51 AM

ElCap 2016 09 21 at 11 21 07 AM

This meant that any process or user could create a directory inside /Volumes or store files there.


World-writable directories are generally seen as a security risk, which may explain why Apple chose to change the permissions on the /Volumes directory. As of macOS Sierra, the permissions on the directory are as follows:

Owner: Read, Write, Execute
Group: Read, Execute
Everyone: Read, Execute

view raw


hosted with ❤ by GitHub

Sierra 2016 09 21 at 8 57 11 AM

Sierra 2016 09 21 at 8 56 42 AM


This change means that the /Volumes directory is readable by anyone but can only be written to by processes using root privileges.

This permissions change should not affect the system’s ability to mount storage devices or fileshares from network servers, as the OS itself is the one handling the mounting and has all the necessary permissions.

  1. NZ
    September 21, 2016 at 8:39 pm

    Damn. Just as I’d rolled out a login script that does a bunch of mkdir /Volumes/bar and mount //foo/bar /Volumes/bar.
    This runs as the AD user to mount selectively based on group membership
    Options :
    -mounting to something in /var, /tmp, ~/ …
    -the “open” command
    -passing a list of shares to a launch agent running as root

    I guess the first option would be the easiest. Open needs Finder, but realistically, by the time Outset starts the script, Finder has been up for a few seconds. The others are ludicrous.

  2. September 25, 2016 at 12:03 pm

    Ahh … maybe that’s why there are tons of dead mountpoint folders …
    In the past … after OSX waking up from sleep mode, sometimes I missed some mounted server shares. Because I’m lazy, i write some Applescript looking for missing shares and remount it. This works without a flaw till Sierra.
    Now it still mounts missing shares, but there are tons of dead mount folder. Something like share-1, share-2, share-3… share-N. In between my mounted mountpoint.

  3. September 27, 2016 at 7:16 am

    Same issue here. I have a script that runs on a cron job that creates a directory in /Volumes and then mounts a server to it using mount_smbfs and then performs an rsync with a folder on the local machine. When it finishes, it unmounts the server and removes the mountpoint directory. After Sierra update it kept failing due to permissions issues on /Volumes. Tried just brute-forcing the permissions of /Volumes to 777 but that only lasted until the next reboot. The fix was to edit the script and everywhere I referenced /Volumes/Public (the mountpoint I was creating) I changed it to /tmp/Public and voila, it all works as it used to. Apple makes weird decisions sometimes.

  4. September 27, 2016 at 6:58 pm

    To those that are using /Volumes as a holding location, I would suggest looking into the command ‘mktemp’ (likely with the -d argument) instead.

  5. Justin Kwasnik
    October 31, 2016 at 9:13 pm

    Apple strikes again…

    I also use rsync to backup specific files and it was only logical to use the /Volumes directory as thats where all mount points reside via afp / smb.

    It looks like in the short term, I will just use the /tmp directory although I will be on the lookout for a solution to use the /Volumes directory without compromising security.

    @Conor – I did try using the mktemp command although it still complains about permissions. I do appreciate you adding your input!!

  6. Glen Ringkøbing Jensen
    November 23, 2016 at 4:31 pm

    Thanks for you feedback James Hasting-Trew did a search/replace with Volumes/tmp and now my Sync services is running again 🙂

  7. Wayne Peacock
    November 30, 2016 at 3:30 pm

    I have noticed that when I change the mount to a different directory and I manually eject a drive, the OS does not clean up the mount points, as it used to in /Volumes. Any ideas?

  8. December 15, 2016 at 9:20 am

    This change also makes Transmit “Mount to Disk” feature unusable 😦

  9. December 16, 2016 at 6:40 pm

    It’s not terrible that Apple did this; what’s terrible is that they didn’t provide any documentation as to how automated processes will work around it. It’s like nobody there knows anything about DevOps.

  10. Jim
    February 3, 2017 at 6:43 pm

    This makes paths to mounted smb drives inconsistent with non-sierra Macs. So links in InDesign are broken every time a different user opens a document.

  11. Jim
    March 1, 2017 at 7:38 pm

    It is a nightmare if some people have upgraded to Sierra and some are on older versions. In InDesign files from one user to another, links don’t recognize the paths anymore, so all placed graphics have to be manually relinked. And then the reverse when it goes back to the original user. So damn annoying and not a peep of how to fix it.

  12. July 28, 2017 at 8:25 am

    well I might have a answer for you guys but cant promise regarding security

    Step 1 : Create folder using sudo mkdir command (if you want to pass password in commandline you can use echo | sudo -S mkdir /Volumes/)

    Step 2 : Now change the ownership of this directory. U can achieve it via sudo chown /Volumes/

    Step 3 (optional): Give the permissions required tho the new directory using chmod.

    Step 4. Mount your directory at the new Directory in /Volumes

  13. Hook Huang
    April 29, 2019 at 1:14 pm

    Want to share a case in re your note that this change should NOT affect mounting disks.

    I have three Mac laptops initially all running Sierra. A few months ago I upgraded one to Mojave. After that upgrade it would not mount any USB drives – while these drives mount just fine on the other two laptops. I reformatted one drive to Apple HFS and it still would not mount. I tried all kinds of remedies and the one that finally worked was to sudo mkdir mountpoint folder in /Volumes then sudo mount and assign the mountpoint folder.

    I initially thought the automatic mount failed because Volumes is only writable by root. However I verified my other laptops that can still mount these drives also have only root writeable for Volumes. So it seems to me there might have been other changes ultimately preventing mountpoint folder to be created under Volume. FYI

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: