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.)
Up to OS X El Capitan, the /Volumes directory was world-writable and had the following permissions:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Owner: Read, Write, Execute | |
| Group: Read, Write, Execute | |
| Everyone: Read, Write, Execute |
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:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Owner: Read, Write, Execute | |
| Group: Read, Execute | |
| Everyone: Read, Execute |
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.
Leave a Reply
Recent Comments
 | Annika on Disabling the Xerox ColorQube… |
 | Thomas B. on 20 years of Der Flounder |
 | peter on 20 years of Der Flounder |
 | Scott Beach on 20 years of Der Flounder |
 | Mr Bombadil on Using Script2Pkg to create pay… |
Der Flounder 
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.
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.
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.
To those that are using /Volumes as a holding location, I would suggest looking into the command ‘mktemp’ (likely with the -d argument) instead.
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!!
Thanks for you feedback James Hasting-Trew did a search/replace with Volumes/tmp and now my Sync services is running again 🙂
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?
This change also makes Transmit “Mount to Disk” feature unusable 😦
Update: Transmit release a fix! You can find it here: https://library.panic.com/transmit/td-install/
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.
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.
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.
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
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