Sandboxing & Problems with Big Sur

Recently I made the mistake of upgrading my Mac to Big Sur. I now can no-longer use Microsoft Office or the Adobe CS5 Suite, and of course licenses are not Transferable so I have thousands of dollars in new licenses to pay (again)… Except I won’t, I’ll just use the old machine for the photographic stuff I do and be damned with Apple and Adobe. Microsoft Word is now OpenOffice. However, by far the most annoying (and why I’ve even considered reverting to El-Capitan) is the new Sandboxing rules that have been imposed.

I do a fair bit of work with FileBot and in years past I made the choice to go with the AppStore version, and bought a license for it way back whenever. Apple have in their infinite wisdom have chosen to impose the restriction that all Apps are Sandboxed when delivered via the AppStore.

Seems like a good idea? Yeah, I thought so as well… until they chose for reasons unknown to restrict where the sandbox will allow you to work.. and it seems it’s impossible to add sanity or override/add paths that a user may require. In my case I have a number of network drives, some 200 Terrabytes of space between them, and as they are a combination of APF, and NFS mounts I had the NFS mounts mounted with the built-in ‘automountd‘ auto mounter. Using the default configuration and adding the shares to ‘/etc/fstab‘ this puts the shares under the default path of ‘/Network/Servers‘. The auto mount works fine, can see all the files and every time I reboot I have to remount the AFP shares as these require credentials associated with the user account and I want them in ‘/Volumes‘.

Not such a good idea anymore…. Sandbox will *NOT* allow access to arbitrary paths and won’t allow access to ‘/Network/Servers‘ any more. Many hours of research have provided no solution and those who could be bothered to log a bug with Apple have found their bugs get closed without comment (and of course no fix.)

So what to do? Well I’m not mounting 10+ shares everytime I login, so went out of my way to get it to present the shares under ‘/Volumes/‘.. not an easy task, AppleScripts work, but not with the right credentials and other really odd issues where they would work sometimes and not others. Big Sur though has had a change that does make the solution work with a bit of scripting and bashing your head against the wall for a few hours.

To save the poor walls around your house/office here’s the way I did it.

First edit ‘/etc/auto_master’ and add/change a few lines… here’s mine:

 # Automounter master map
 +auto_master            # Use directory service
 /net                    -hosts          -nobrowse,hidefromfinder,nosuid
 /home                   auto_home       -nobrowse,hidefromfinder
 /Network/Servers        -fstab
 /-                      -static
 /-                      auto_afp        -nobrowse,nosuid
 /-                      auto_smb        -nobrowse,nosuid
 /-                      auto_nfs        -nobrowse,nosuid

Next create/edit:


(Note: in my case auto_smb is an empty file as I don’t have SMB mounts currently)

My /etc/auto_afp file:

/System/Volumes/Data/Volumes/Downloads          -fstype=afp,rw afp://*username*:*password*@*IP-address-of-NAS*:/Downloads
/System/Volumes/Data/Volumes/TV                 -fstype=afp,rw afp://*username*:*password*@*IP-address-of-NAS*:/TV
/System/Volumes/Data/Volumes/Movies             -fstype=afp,rw afp://*username*:*password*@*IP-address-of-NAS*:/Movies
/System/Volumes/Data/Volumes/Music              -fstype=afp,rw afp://*username*:*password*@*IP-address-of-NAS*:/Music
/System/*username*/Data/Volumes/Videos             -fstype=afp,rw afp://*username*:*password*@*IP-address-of-NAS*:/Videos
/System/Volumes/Data/Volumes/Transmission       -fstype=afp,rw afp://*username*:*password*@*IP-address-of-NAS*:/Transmission

My /etc/auto_nfs file:

/System/Volumes/Data/Volumes/Storage            -fstype=nfs,noowners,noresvport,hard,bg,intr,rw,tcp,rdirplus,rsize=65536,wsize=65536,readahead=128      nfs://*StorageServer1*/Storage
/System/Volumes/Data/Volumes/Archive              -fstype=nfs,noowners,noresvport,hard,bg,intr,rw,tcp,rdirplus,rsize=65536,wsize=65536,readahead=128      nfs://*StorageServer2*/Archive

Now, you’d think this would be all good, just run ‘sudo automount -vc‘ and you’d be good to go right? Wrong! automountd will not create directories, so create them and run ‘sudo automount -vc‘ and you’ll be good to go… well until you reboot… The ‘/Volumes/‘ directories that appeared when you created the directories under “/System/Volumes/Data/Volumes” are deleted/removed on reboot, so the auto mounter can’t mount anything the next time around and you have to create the directories all over again. A bit of searching, reading manual pages and it appears ‘/etc/synthetic.conf‘ would solve it… Wrong again! <insert expletives aimed at Apple>..

The solution is to get launchd to create the directories for you and tell automountd to flush the cached information (and therefore reload everything).. so just add the following files:

File: /Library/Scripts/



for mapfile in `cat /etc/auto_master | grep -- '^/-' | awk '{print $2}' | grep ^auto_`
    # here we should have all the /etc/auto_* files so iterate
    for dir in `cat /etc/${mapfile} | grep '^/' | awk '{print $1}'`
        # here we should have a list of directories to create
        mkdir -p ${dir}

Save the file and make it executable with:

chmod +x /Library/Scripts/

Next create a plist description for launchd here: /Library/LaunchDaemons/

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "">
<plist version="1.0">
    <key>Label</key>             <string></string>
    <key>Disabled</key>          <false/>
    <key>RunAtLoad</key>         <true/>
    <key>KeepAlive</key>         <false/>

Finally, you can load it with:

sudo launchctl -w /Library/LaunchDaemons/

…and for the final test… just reboot, you should find all your mounts reappear on reload.