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:

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:

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.

  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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s

%d bloggers like this: