Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
Automounting NFS share in OS X into /Volumes

I have spent quite a bit of time figuring out automounts of NFS shares in OS X...

Somewhere along the line, Apple decided allowing mounts directly into /Volumes should not be possible:

/etc/auto_master (see last line):

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

/etc/auto_nfs (this is all one line):

/Volumes/my_mount    -fstype=nfs,noowners,nolockd,noresvport,hard,bg,intr,rw,tcp,nfc nfs://192.168.1.1:/exports/my_share

Make sure you:

sudo chmod 644 /etc/auto_nfs

Otherwise the automounter will not be able to read the config and fail with a ... parse_entry: getmapent for map failed... error in /var/log/messages

This will not work (anymore!) though it "should".

$ sudo automount -cv
...
automount: /Volumes/my_mount: mountpoint unavailable

Note that, if you manually create the mount point using mkdir, it will mount. But, upon restart, OS X removes the mount point, and automounting will fail.

What's the solution?

It's so easy my jaw dropped when I figured it out. Basically, we trick OS X into thinking we're mounting somewhere else.

When you're talking about paths in just about any environment, the root folder is the highest path you can reach, whether it's C:\ (windows) or / (*nix)

When you're at this path, attempting to reach the parent path, via .. will keep you at the root path.

For example: /../../../../ is still just /

By now, a few of you have already figured it out.

TL;DR / Solution:

Change your /etc/auto_nfs config from (this is all one line):

/Volumes/my_mount    -fstype=nfs,noowners,nolockd,noresvport,hard,bg,intr,rw,tcp,nfc nfs://192.168.1.1:/exports/my_share

For pre-Catalina: To (this is all one line)

/../Volumes/my_mount    -fstype=nfs,noowners,nolockd,noresvport,hard,bg,intr,rw,tcp,nfc nfs://192.168.1.1:/exports/my_share

For Catalina and up: To (this is all one line)

/System/Volumes/Data/../Data/Volumes/my_mount    -fstype=nfs,noowners,nolockd,noresvport,hard,bg,intr,rw,tcp,nfc nfs://192.168.1.1:/exports/my_share

And re-run the automounter:

$ sudo automount -cv
...
automount: /Volumes/my_mount: mounted

..... there you go! Technically /../Volumes is still /Volumes, but the automounter does not see things that way ;)

This configuration persists the mount across restarts, and creates the mountpoint automatically.

I KNOW, RIGHT?

Feel free to send me large checks and/or high five the screen. hitmeup@l422y.com

@Leland

This comment has been minimized.

Copy link

@Leland Leland commented Aug 13, 2014

You, sir, are a prince. Also, this still works in Yosemite

@ershler

This comment has been minimized.

Copy link

@ershler ershler commented Aug 20, 2014

OK, now I freely admin that I am a dumb shit. I followed your instructions and sudo automount -cv successfully mounts my_mount. So I end up with the following from a df command.
map auto_home 0 0 0 100% 0 0 100% /home
rex.cvrti.utah.edu:/Volumes/NETDIR/people 15625000000 6692736432 8932263568 43% 418296025 558266473 43% /home/.hidden
map /etc/auto_nfs 0 0 0 100% 0 0 100% /Volumes/people
155.100.140.16:/Volumes/NETDIR/people 15625000000 6692736432 8932263568 43% 418296025 558266473 43% /Volumes/people

But, I'd like to use your ideas to auto mount NFS network home directories. Now my OS X server that holds the network home directories exports
/Volumes/NETDIR/people
All the user directories are under people.

In my OD master, my user home directories are just described as /people. How do I get your auto_nfs to mount things so that the user sees his/her network home directories? As it is now, if I log some into this Yosemite machine I end up with a people directory created on / and a user directory with the correct name with an new "empty" OS X directory.

dhcp-155-100-140-105:~ bridge$ pwd
/people/bridge
dhcp-155-100-140-105:~ bridge$ ls -l
total 0
drwx------+ 3 bridge cvrti 102 Aug 19 19:01 Desktop
drwx------+ 3 bridge cvrti 102 Aug 19 19:01 Documents
drwx------+ 4 bridge cvrti 136 Aug 19 19:01 Downloads
drwx------@ 37 bridge cvrti 1258 Aug 19 19:02 Library
drwx------+ 3 bridge cvrti 102 Aug 19 19:01 Movies
drwx------+ 3 bridge cvrti 102 Aug 19 19:01 Music
drwx------+ 3 bridge cvrti 102 Aug 19 19:01 Pictures
drwxr-xr-x+ 4 bridge cvrti 136 Aug 19 19:01 Public

Your help to lead this dumb shit out of the darkness would be very much appreciated. Right now all my users are running 10.8.5 and are screaming to get to Mavericks.

@ershler

This comment has been minimized.

Copy link

@ershler ershler commented Aug 20, 2014

Never mind. All I had to do was remove the /people directory and replace it with soft link to /Volumes/people. At that point everything works perfectly. Many, many thanks for your efforts!

@kai-h

This comment has been minimized.

Copy link

@kai-h kai-h commented Aug 25, 2014

This works - except although I get the required device mounted in /Volumes/sharepoint, it doesn't show up on the desktop as a mounted server volume. It is mounted as AFP, using /../Volumes/sharepoint -fstype=afp afp://username:password@server.example.com/sharepoint in my auto_afp file (chmod'd 600 as I've got a password in it)

@L422Y

This comment has been minimized.

Copy link
Owner Author

@L422Y L422Y commented Aug 31, 2014

you can just create a link to the /Volumes/sharepoint folder, and place it on your desktop.

@RJVB

This comment has been minimized.

Copy link

@RJVB RJVB commented Nov 21, 2014

So this worked for me for a while (in a VM, even), but now I get something very weird.

First, my auto_master:

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

and auto_nfs:

/../Volumes/patux-home/bertin      -fstype=nfs,nolocks,locallocks,intr,soft,wsize=32768,rsize=32768,noauto,rw,tcp,nfc      nfs://patux.local/home/bertin
/../Volumes/patux-home/nsynced  -fstype=nfs,nolocks,locallocks,intr,soft,wsize=32768,rsize=32768,noauto,rw,tcp,nfc      nfs://patux.local/home/nsynced
> sudo automount -cv
automount: /net updated
automount: /home updated
automount: /Volumes/patux-home updated
automount: /../Volumes/patux-home/bertin: Can't convert to real path: Permission denied
automount: /../Volumes/patux-home/nsynced: Can't convert to real path: Permission denied
automount: no unmounts

Nowhere do I tell the system to mount anything on /Volumes/patux-home (or so I think). And worse, even root cannot read nor delete /Volumes/patux-home . It's only when I boot under 10.6 that I can see that that directory indeed contains the two actual mountpoints ...

>  mount
/dev/disk2s2 on / (hfs, local, journaled)
devfs on /dev (devfs, local, nobrowse)
map -hosts on /net (autofs, nosuid, automounted, nobrowse)
map auto_home on /home (autofs, automounted, nobrowse)
zVMS/VM on /Volumes/VMS (zfs, local, noatime)
zVMS/VM/zLinux on /Volumes/VMS/VM/Linux (zfs, local, noatime, nobrowse)
zVMS/VM/zhostside on /Volumes/VMS/VM/hostside (zfs, local, noatime, nobrowse)
zVMS/VM/zvirtSim36 on /Volumes/VMS/VM/virtSim36_zVMS (zfs, local, noatime, nobrowse)
zVMS/OPT/crossdevel on /opt/cross (zfs, local, noatime, nobrowse)
zVMS/OPT/MacPorts-10.9/varBuild on /Volumes/Debian/MP9/var/macports/build (zfs, local, noatime, nobrowse)
map -static on /Volumes/patux-home (autofs, automounted, nobrowse)

Thoughts?

@6twenty

This comment has been minimized.

Copy link

@6twenty 6twenty commented Dec 16, 2014

Everyone, heads up: if you automount to /Volumes (aka /../Volumes) you may have issues mounting any other filesystems. This includes external USB drives and disk images (DMG, ISO, etc). I experienced this in Yosemite, and it was due to autofs deleting the /Volumes directory and re-creating it as a mount point which has different permissions that can't be changed.

@breu

This comment has been minimized.

Copy link

@breu breu commented Feb 9, 2015

You can also use /net/hostname/path if using NFS. Not sure about other protocols. Works on my Yosemite.

@bjuren

This comment has been minimized.

Copy link

@bjuren bjuren commented Sep 18, 2015

Have anyone tried adding Volumes to the Dock? The name of the shares are somewhat not correct accordlingly to the Shares in the mount file.

@timkelty

This comment has been minimized.

Copy link

@timkelty timkelty commented Oct 29, 2015

The problem I'm still having with all this is that my volume gets mounted owned by root:wheel. Therefore, I can't even cd into them.

@13eastie

This comment has been minimized.

Copy link

@13eastie 13eastie commented Nov 1, 2015

Many thanks, lawrencealan – I've been suffering from this issue since upgrading to a long-forgotten version of OS X ( (I'm now using El Capitan) to connect to a shared drive on my faithful home Ubuntu server.

On my MacBook:

sh-3.2# stat -f %Mp%Lp /etc/auto_nfs
0644
sh-3.2# cat /etc/auto_nfs
/../Volumes/share -fstype=nfs,noowners,nolockd,noresvport,hard,bg,intr,rw,tcp,nfc nfs://192.168.0.10:/home/share
sh-3.2# mount
/dev/disk1 on / (hfs, local, journaled)
devfs on /dev (devfs, local, nobrowse)
map -hosts on /net (autofs, nosuid, automounted, nobrowse)
map auto_home on /home (autofs, automounted, nobrowse)
map auto_nfs on /Volumes/share (autofs, nosuid, automounted, nobrowse)
localhost:/yu3ZQ6yl2KH4XIseZSXEWK on /Volumes/MobileBackups (mtmfs, nosuid, read-only, nobrowse)
sh-3.2# ls -l /Volumes/
total 26
-rw-r--r--@ 1 502   admin  6148 18 Mar  2012 .DS_Store
lrwxr-xr-x  1 root  admin     1  1 Nov 15:23 Macintosh HD -> /
drwxrwxrwx  0 root  wheel     0  1 Nov 15:23 MobileBackups
dr-xr-xr-x  2 root  wheel     1  1 Nov 15:23 share
sh-3.2# ls -l /Volumes/share
ls: share: Operation not permitted
sh-3.2# mount -t nfs -o resvport 192.168.0.10:/home/share /mnt/share
sh-3.2#

Only after the issue of the final command does the shared folder actually become accessible (which is why I've been running a script to this effect for years).

Salient points here are:

  1. The behaviour of NFS can be sensitive to port numbers being used. The message "Operation not permitted" in response to the ls command indicates that this may be the problem.
  2. If you are getting this error message, then the solution is to alter your entries in /etc/auto_nfs to include resvport rather than noresvport (see here for a bit more explanation).
  3. This approach will mount your shares automatically at boot-time, but will not make the sharing server visible in the side-bar of Finder (like AFP shares are, like NFS shares do if they are mounted manually, and like how I'm sure NFS shares used to be when configured straightforwardly using Disk Utility under older versions of OS X), which is what I really would like. My view is that auto-mounted shares should look and behave exactly the same as if they had been mounted manually – I'd be very grateful for any pointers as to how to make this happen, cheers.

Aside
There is a lot of banter around about Apple continuing to favour SMB over other sharing protocols which seems to me to be at odds with the reality that "home" (almost, by definition, Apple) users are, like me, very often running open-source UNIX-like OS's as headless media servers. Even if they are using Plex clients or DNLA (or whatever) they still need to manage their content somehow and CIFS and AFP seem to be rather clumsy compared to NFS as a means of doing this.

@prologic

This comment has been minimized.

Copy link

@prologic prologic commented Dec 29, 2015

Did anyone fix the issue with the share not being visible in Finder?

@robmoggach

This comment has been minimized.

Copy link

@robmoggach robmoggach commented Jan 11, 2016

using the nobrowse option will probably hide mounts as volumes in the finder - try without that

if you want a full list of options...

Mac OS Documentation: auto_master -- automounter master map

@RJVB

This comment has been minimized.

Copy link

@RJVB RJVB commented Jan 27, 2016

After somehow getting rid of the error message (and "ghost" directory) mentioned in a previous commit this has been working almost flawlessly for me.
Now, after upgrading to kernel 3.14.59 on my Kubuntu box, I noticed

  • kernel console messages about nfs on Kubuntu (about a tainted module as far as I could see)
  • messages in system.log that my nfs server wasn't responding, and the corresponding symptoms when trying to access the mounts.

I could still do parallel mounts of the same shares, so the underlying issue must have had to do with Apple's automounting service. Since I already had one of the shared configured via /etc/fstab (the automounter doesn't accept nested mount points) I have now moved everything into /etc/fstab. In the end I prefer reliable functioning (and the possibility to -force- unmount the shares if required) over all the hassles that come with trying to get them mounted automatically.

@gvn

This comment has been minimized.

Copy link

@gvn gvn commented Feb 16, 2016

Like @6twenty, I also experienced other USB devices being clobbered (specifically a USB Blu-Ray drive), so I switched to using /Mount/NAME for my nfs share instead.

So far, so good!

@Patrick1610

This comment has been minimized.

Copy link

@Patrick1610 Patrick1610 commented Mar 28, 2016

Hi,

Can you limit the automount function to a specific network?
I would like it if my MacBook mounts my NAS drives when I am at home, but without trouble on other networks.

@TomKaltz

This comment has been minimized.

Copy link

@TomKaltz TomKaltz commented Mar 28, 2016

When does the user-created mount directory get deleted by OSX? Can we use launchd to recreate the directory and run automount?

@MichalMMac

This comment has been minimized.

Copy link

@MichalMMac MichalMMac commented May 20, 2016

@timkelty

To prevent automounting with root 700 permissions use indirect map instead of direct (See AutoFS whitepaper)

@exenza

This comment has been minimized.

Copy link

@exenza exenza commented Jul 8, 2016

Another solution a little bit more hacky is to leverage Applescript for the mount, the cons are that you need to use a custom script and is a little more tedious to setup, the advantages are that the credentials are stored in keychain and this solution should be more resistant to apple updates, I believe fooling the Volumes path is a bug which may be addressed at some point.

Here the whole explanation: http://nas-ho.me/?p=234

@MrBobb

This comment has been minimized.

Copy link

@MrBobb MrBobb commented Sep 5, 2016

Many thanks for the clearly detailed steps!
I think I replicated all of them but I must be doing something wrong because in the end I'm not able to see the content of my mounted NFS share.

My auto_nfs file looks like this:
/../Volumes/VideoEditing -fstype=nfs,noowners,nolockd,noresvport,hard,bg,intr,rw,tcp,nfc nfs://192.168.1.104:/exports/VideoEditing

From what I can judge, "VideoEditing" share is mounted. I see it in Finder under Shared / Servers / nfs / VideoEditing. Problem is that no file appears here. The "VideoEditing" share is located on a QNAP NAS where read/write permissions are set.

It looks like no rights are set to access sub-folders in the share.
Did anyone encounter a similar problem?

@zxfrank

This comment has been minimized.

Copy link

@zxfrank zxfrank commented Sep 16, 2016

Hello, I used your trick to mount my nfs share. It mount but I can't list or access it.
I always end with "ls: : Permission denied" as a user and with sudo

OSX ElCapitan v10.11.6
My nfs server is OpenFiler

(could be the same issue as MrBobb)
thanks for your help

@DaveAlton

This comment has been minimized.

Copy link

@DaveAlton DaveAlton commented Dec 17, 2016

Every new folder created within my share is "read only" and I have to 'chmod' every time I create a folder. Is there a way to set permissions of new folders?

@MacBadger

This comment has been minimized.

Copy link

@MacBadger MacBadger commented Aug 20, 2017

You might find this useful:
http://blog.grapii.com/2015/06/keep-network-drives-mounted-on-mac-os-x-using-autofs/

It also addresses' the 'Volumes' issue without causing problems.

@aidyw

This comment has been minimized.

Copy link

@aidyw aidyw commented Nov 16, 2018

Regarding getting mounts visible in Finder even across reboots. Here is a 'workaround'
Firstly dont mount directly into /Volumes. Instead create a suitable directory somewhere you are happy with. I choose the root of the mac's harddrive and named according to the server I was connecting to.
eg.

sudo mkdir /My_Server

Then use the autofs facility as described at the top of this post to create a set of mount points within this directory

/My_Server/my_mount1     -fstype=nfs,nfsvers=4,rw mx.shared-sun.com:/mnt/shared_sun_NAS/Music
/My_Server/my_mount2     -fstype=nfs,nfsvers=4,rw mx.shared-sun.com:/mnt/shared_sun_NAS/Pics

Of course if it is an NFS3 share you need to use the appropriate mount option in this autofs stanza.

Now mount them:

automount -cv

Now they are mounted. Open Finder and browse to the mount points. You can then use Finder to drag the individual mount point directories into the Devices side bar area.
An important note here. You may drag a directory called, in this example, 'my_moun1' BUT it will appear in the Devices sidebar as 'Music'. This is upside down. The only name that appears in the devices side bar is the name of the actual export directory on the server. Go figure? But hey, at least you can tell one server apart from another by placing all the mount points from a common server in the same root directory. I have no idea what Finder will do if you have 2 servers with identically named exports.

I would suggest shuffling the mounts in the side bar up to the top, they are then mounted before any other slower devices like for example USB sticks.
Enjoy!

@apwelsh

This comment has been minimized.

Copy link

@apwelsh apwelsh commented Oct 8, 2019

No longer works in catalina. Hope someone finds another workaround.

@L422Y

This comment has been minimized.

Copy link
Owner Author

@L422Y L422Y commented Oct 9, 2019

No longer works in catalina. Hope someone finds another workaround.

Well... had a good run? :)

@L422Y

This comment has been minimized.

Copy link
Owner Author

@L422Y L422Y commented Oct 9, 2019

No longer works in catalina. Hope someone finds another workaround.

Try this... in auto_nfs:

/System/Volumes/Data/Volumes/mymntpoint -fstype=nfs,noowners,nolockd,noresvport,hard,bg,intr,rw,tcp,nfc nfs://10.0.0.91/exports/my_share

mounts to /Volumes/mymntpoint

@davidrothera

This comment has been minimized.

Copy link

@davidrothera davidrothera commented Oct 10, 2019

@L422Y - The mount dir (/System/Volumes/Data/Volumes/mymntpoint in your example) isn't persisting a reboot for me and I have to re-create it every boot, is that the same for you?

@L422Y

This comment has been minimized.

Copy link
Owner Author

@L422Y L422Y commented Oct 10, 2019

@L422Y - The mount dir (/System/Volumes/Data/Volumes/mymntpoint in your example) isn't persisting a reboot for me and I have to re-create it every boot, is that the same for you?

well... derp... i guess one of the commands i ran created the directory.
so far no luck at circumventing this time... at this point registering a launch daemon is probably the best option:

https://apple.stackexchange.com/questions/229209/launchd-script-to-mount-volume-on-boot

@oddly-fixated

This comment has been minimized.

Copy link

@oddly-fixated oddly-fixated commented Oct 19, 2019

Since the automounter is a piece of crap, I switched to launchd. I claim no particular expertise with launchd - nothing beats SysV init IMHO. Get off my lawn.

I completed these steps manually using $EDITOR, but the here document hacks below should be fine. Understand what you're doing before you copy/pasta and turn your Mac into a paperweight. Substitute some-user for whatever suits you. YMMV.

  1. Create a script to complete a mount operation.
cat > /Users/some-user/bin/nas.sh <<EOF
#!/bin/sh

mount -o rw,bg,hard,resvport,intr,noac,nfc,tcp nas:/volume/Music /Users/some-user/Music
mount -o rw,bg,hard,resvport,intr,noac,nfc,tcp nas:/volume/Movies /Users/some-user/Movies
EOF
  1. Make the script executable.
    chmod 755 /Users/some-user/bin/nas.sh

  2. Create a /Library/LaunchDaemons file.

sudo cat > /Library/LaunchDaemons/com.some-user.nas.plist <<EOF
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>

    <key>Label</key>
    <string>com.some-user.nas</string>

    <key>RunAtLoad</key>
    <true/>

    <key>StandardErrorPath</key>
    <string>/Users/some-user/logs/nas.sh.stderr.log</string>

    <key>StandardOutPath</key>
    <string>/Users/some-user/logs/nas.sh.stdout.log</string>

    <key>WorkingDirectory</key>
    <string>/Users/some-user/bin</string>

    <key>ProgramArguments</key>
    <array>
      <string>/Users/some-user/bin/nas.sh</string>
    </array>

  </dict>
</plist>
EOF

You don't really need to catch STDERR and STDOUT, so you can omit the StandardErrorPath and StandardOutPath keys with their respective strings. I suppose WorkingDirectory is redundant given nas.sh is called using its full path.

  1. Launch it.
    launchctl load /Library/LaunchDaemons/com.some-user.nas.plist

  2. Check your mounts.
    mount | grep nfs

@thegodsquirrel

This comment has been minimized.

Copy link

@thegodsquirrel thegodsquirrel commented Oct 23, 2019

"There is no way it could be this easy..."

"Changed /Mounts/weblinux2-munki.thevalley.nl to /System/Volumes/Data/Mounts/weblinux2-munki.thevalley.nl in /etc/auto_nfs and issue resolved".

(i.e., replace "/../" with "/System/Volumes/Data/Mounts/..."

It works.

CREDIT!!!!

https://discussions.apple.com/thread/250741805

@aydh

This comment has been minimized.

Copy link

@aydh aydh commented Nov 19, 2019

That still didn't mount it in /Volumes I found this works:

/System/Volumes/Data/../Data/Volumes/media

@apwelsh

This comment has been minimized.

Copy link

@apwelsh apwelsh commented Nov 19, 2019

The /../ is not necessary. It works using the real mounted location (/System/Volumes/Data/Volumes) provided you first create the target folder. In your scenario, did you have to first create the target folder?

@aydh

This comment has been minimized.

Copy link

@aydh aydh commented Nov 19, 2019

Nope, creates the folder for you

@davidrothera

This comment has been minimized.

Copy link

@davidrothera davidrothera commented Nov 19, 2019

Confirmed that the fix from @aydh works and creates the folder for me as well

@L422Y

This comment has been minimized.

Copy link
Owner Author

@L422Y L422Y commented Nov 19, 2019

A few of us tried this and the folder seems to get deleted at times and not recreated, I'll wait a while on feedback – but it looks like the .. trick combined with the /System/Volumes/Data modification works... cool!

@apwelsh

This comment has been minimized.

Copy link

@apwelsh apwelsh commented Nov 19, 2019

Thanks for the feedback. I will implement the relative path solution to see if it auto-creates the folder for me too.

@jefro108

This comment has been minimized.

Copy link

@jefro108 jefro108 commented Nov 26, 2019

ConnectMeNow v3 – Mount Network Shares Quick and Easy on a Mac - free app seems to do the mounting of NFS shares all for me - see https://www.tweaking4all.com/os-tips-and-tricks/macosx-tips-and-tricks/connectmenow-v3/ and mounts them in the /Volumes folder!

@apwelsh

This comment has been minimized.

Copy link

@apwelsh apwelsh commented Nov 26, 2019

Just a follow-up. I did manage to verify this works for me. My mount path looks like:
/System/Volumes/Data/../Data/Volumes/Drobo

Running “sudo automount -cv” results in the folder being created and mounted for all concurrent users without issue.

I was able to confirm the the /../ must be after /Data/. Placing the relative parent path at Volumes or later fails to create the folder.

@L422Y

This comment has been minimized.

Copy link
Owner Author

@L422Y L422Y commented Nov 26, 2019

I was able to confirm the the /../ must be after /Data/. Placing the relative parent path at Volumes or later fails to create the folder.

Great!

@lordmorgul

This comment has been minimized.

Copy link

@lordmorgul lordmorgul commented Nov 29, 2019

I found that using /../Volumes was not working for me on Catalina, still gave the error "mountpoint unavailable" but I could use a single dot.
/System/Volumes/Data/./Volumes/blah worked just fine. However it is still having MANY separate listings under 'df' for the mount points so appears to be frequently unmounting and remounting (or just remounting) since you cannot unmount it cleanly. My NFS share mountpoint gets 'busy' and cannot be unmounted or cleared until reboot even manually unmounting it and trying to delete the directory in /Volumes.

Thinking use of automount in Catalina is just broken enough that the launch daemon is the best approach. I use launch daemons to mount SMB shares (with auto checking that connected to my wifi first) already so working on a solution to use it for NFS too.

@apwelsh

This comment has been minimized.

Copy link

@apwelsh apwelsh commented Nov 29, 2019

“ I found that using /../Volumes was not working for me on Catalina”

The .. means parent. So, if your Mount point was Data/../Volumes then it would be wrong It needs to be either Data/./Volumes (as you discovered) or Data/../Data/Volumes.

@lordmorgul

This comment has been minimized.

Copy link

@lordmorgul lordmorgul commented Dec 7, 2019

“ I found that using /../Volumes was not working for me on Catalina”

The .. means parent. So, if your Mount point was Data/../Volumes then it would be wrong It needs to be either Data/./Volumes (as you discovered) or Data/../Data/Volumes.

Sorry that's a lazy typo in my reply, yes, it would be necessary to have Data listed twice but that does not work on my system, mount refuses to use it (corrected as you mentioned). Whereas, the single dot self-reference does work (in that case not duplicating Data).

I've abandoned NFS mount on OSX Catalina due to the issues with continuous disconnect and re-mount that results in multiple listings for active mounts of the same path. It creates many until the system crashes, and if you try to unmount them you have to unmount -f each one until no more mounts of that path exist before you can clean up the folders in Volumes. So I'm not using NFS or automount at all.

Instead I'm using SMB and a user mount to the Volumes location by a registered launch agent. I'd been doing that for years for a local cloud drive and just trying to make NFS work properly for an automated backup system change (just because) and had to give up on it.

I use these files, with appropriate changes to try to use the NFS or SMB format if someone wanted to, and the local wifi names, paths, usernames, and SMB passwords as necessary. This way when I grab the system and leave, it just unmounts for me, and when I'm home it remounts.

https://gist.github.com/lordmorgul/50f20697cf2390e343a17e59b9457764

@apwelsh

This comment has been minimized.

Copy link

@apwelsh apwelsh commented Dec 8, 2019

Whatever works is really what this comes down to. But I can confirm I use multiple users in my Mac, and it does not exhibit the auto-disconnect behavior. NFS is the only
Viable option for me, because SMB does not allow multiple users to mount the same share to the same folder. And in my system, I specifically need this. The one key thing for me is that my NFS server is also a Mac running Catalina.

@thegodsquirrel

This comment has been minimized.

Copy link

@thegodsquirrel thegodsquirrel commented Dec 14, 2019

I can mount this drive to my desktop and hide it and this works on the most current Catalina update.

The /etc/auto_master file is overwritten after every new update. You must re-add this line to the file after each update:

/- auto_nfs -nobrowse,nosuid

This is currently working as of today in my /etc/auto_nfs config file:

/System/Volumes/Data/Users/"myusername"/Desktop/data4 -fstype=nfs,nodev,noresvport,hard,bg,intr,rw,tcp,nfc "some_IP_Address":/export/mnt/media/data4

@apwelsh

This comment has been minimized.

Copy link

@apwelsh apwelsh commented Dec 14, 2019

If you are mounting in your home directory, I would recommend considering AFP or SMB as both are more modern than NFS and may better suite your needs. NFS is better suited as the only solution when you need more than one user to mount the share on the same local path at the same time — but still be accessing the volume as separate users.

@L422Y

This comment has been minimized.

Copy link
Owner Author

@L422Y L422Y commented Dec 14, 2019

If you are mounting in your home directory, I would recommend considering AFP or SMB as both are more modern than NFS and may better suite your needs. NFS is better suited as the only solution when you need more than one user to mount the share on the same local path at the same time — but still be accessing the volume as separate users.

NFS is faster, has less overhead, and puts less load on the server. YMMV depending on the environment, but in all of my real world use cases, with an abundance of testing, NFS has always come out on top – I only use AFP or SMB in environments where NFS is not acceptable to use... when things need to be easy.

@Michelasso

This comment has been minimized.

Copy link

@Michelasso Michelasso commented Feb 19, 2020

Also with SMB it worked just fine as before Catalina, thanks!! Not sure what to make out of that "/../" thingy, though. It makes no sense to me. But well.. Now it works!

@L422Y

This comment has been minimized.

Copy link
Owner Author

@L422Y L422Y commented Feb 19, 2020

Not sure what to make out of that "/../" thingy

When navigating filesystems, a single period . refers to the current directory, and .. refers to the parent directory – just a way to trick the system into thinking we were mounting not inside /Volumes – I'm fairly certain it was hard-coded to be blocked, so /Volumes triggered the block but /../Volumes did not.... maybe :)

@Michelasso

This comment has been minimized.

Copy link

@Michelasso Michelasso commented Feb 23, 2020

@ L422Y yeah, I suppose so. Although I also tried with /../System/Volumes/Data/Volumes/NAS326 and that didn't work. "automount -cv" reported
automount: /System/Volumes/Data/../System/Volumes/Data/Volumes/NAS326: Operation not permitted

Also other combinations gave similar error message. Not sure why Apple had to break it on purpose.

Anyway, is there an option to make the drive folder appearing in Finder?

@apwelsh

This comment has been minimized.

Copy link

@apwelsh apwelsh commented Feb 23, 2020

The auto-mount path you used is entered wrong. Based on the error, I would suggest you make the line look like:

For NFS

/System/Volumes/Data/./Volumes/Videos -fstype=nfs,noresvport,soft,bg,rw nfs://192.168.0.100:/volume1/Videos

For AFP

/System/Volumes/Data/./Volumes/Shared -fstype=afp,rw afp://192.168.0.100:/Shared

Now, my Videos are mounted to /Volumes/Videos. The NFS share on my Synology is on volume 1, and and the share is called Videos. For AFP and SMB, the share name is all you need, and the volume is ignored.

Assuming you have that part right, and I suspect you do since your error is in regards to the mount point, the mount point should look like mine do. put the full path in, then after data add the /./ path reference. if you want to you /../ you can, but there would be more typing: Here is my AFP share with /../

/System/Volumes/Data/Volumes/../Volumes/Shared -fstype=afp,rw afp://192.168.0.100:/Shared
The Idea is that your relative path reference should occur under the Data path to trick the parser into allowing the path. But also because the Data volume is where your writable data is actually at.

Some key points, make sure you also use the IP address of your NAS, and that your NAS get assigned a reserved IP address, or you will have mount issue at boot up.

How to auto mount drive on desktop
You can't. An automount drive is an extension of the filesystem. The best you can do is create a symbolic link on your desktop that points to the mount point.

To do this, from the Terminal:

ln -s /Volumes/Shared ~/Desktop/Shared

Then in my Desktop, I see a Link that looks similar to the share.
image

This is not the same thing though. You cannot eject this drive. If you want to mount the drive automatically in a way that behaves exactly like the drives you mount manually, then you don't want to use autmout. Instead you should use a script to mount the drive, and run that script at login. For that method, look at this: Automatically Connect to a Network Drive. on Mac OS X Startupp and Login. This method is uses the scripting engine on your Mac to automated he. mounting.

autofs and automount are technologies that integrate into your drive to mount remote shares into any folder when the folder is accessed and to make it appear as part of the local file-system. I do not think this is what you want. I think you want to use the mounting script to make use of the system's drive mounter instead.

@Michelasso

This comment has been minimized.

Copy link

@Michelasso Michelasso commented Feb 24, 2020

Thanks for the extensive reply! I'll test it wiyh the "/./" in the path. Still just one thing:

This is not the same thing though. You cannot eject this drive. If you want to mount the drive automatically in a way that behaves exactly like the drives you mount manually, then you don't want to use autmout. Instead you should use a script to mount the drive, and run that script at login. For that method, look at this: Automatically Connect to a Network Drive. on Mac OS X Startupp and Login. This method is uses the scripting engine on your Mac to automated he. mounting.

The issue is that I need to automount the share because I'm using it from my MacBook Pro. Which I take to work and when I come back I want it to automatically reconnect (as it does) to my NAS. So I am guessing it isn't possible to get the drive icon only when it's (auto)mounted, like, for example, an USB drive.

Oh well, it isn't a big issue. It would have been just cool. Thanks!

@apwelsh

This comment has been minimized.

Copy link

@apwelsh apwelsh commented Feb 24, 2020

There are a couple issues with your scenario. The first is that you will need to make sure the mount is a soft mount, or else you risk the filesystem locking up from what I have experienced. When you leave home, and the suddenly disappears, the NFS automounter will go out to lunch waiting for the NAS to come back online. The second issue is that of the drive icon. You could certainly create an automatic script that monitors the folder for change, and when detected, runs to create or delete the symbolic link on the desktop. This can be difficult to code, but once you get it right, it should work.

The easy solution for your issue is to use a utility to handle the mounts for you. I have used Expandrive for this. Since this is not a multi-user situation, you don’t need NFS, so I would use an AFP share or an SMBv3 share (as these are the fastest) but they are limited to single user access to the mount, unless you make them accessible by the guest/ anonymous user account (not recommended). Expandrive can mount all your NAS drive resources on demand, as well as many cloud drive services, and even SFTP/SSH paths as mountable resources. There are other mounting utilities as well, and you can surely do this with Automator scripts. But this autofs solution probably isn’t the right tool for this. At least, I would not use it for your situation. This is exactly what I use Expandrive for on my MacBook. Expandrive is not free, and they make you pay for every major version upgrade.

@jefro108

This comment has been minimized.

Copy link

@jefro108 jefro108 commented Feb 24, 2020

@Michelasso I suggest using the free app ConnectMeNow, which will auto-mount on start and on network change, so may do what you want, and for free! It is so much easier to set up and doesn't have the drawback of needing to re-edit /etc/auto_master after a system update - plus you see the server mounted on the desktop 😊

@apwelsh

This comment has been minimized.

Copy link

@apwelsh apwelsh commented Feb 24, 2020

Great alternative!

@Michelasso

This comment has been minimized.

Copy link

@Michelasso Michelasso commented Feb 27, 2020

@jefro108 Ok, so I gave it a try at ConnectMeNow and.. it works! It's a bit not very intuitive to set it up (and one must go into the advanced settings to enable the automount after a network change), still it's only a matter of few minutes if one knows what he's doing. Also it's probably better than rewriting /etc/auto_master after each macOS update indeed.. I have disabled the SMB mounts for automount and I am starting using this instead. Lets' see how it goes!

PS: @apwelsh, yeah, I knew about the soft option for NFS. But NFS on my NAS is a nightmare (very slow) so I just use SMB. Still, thanks to both! 😀

@AdamCBernstein

This comment has been minimized.

Copy link

@AdamCBernstein AdamCBernstein commented Jul 10, 2020

My "struggle" with getting MacOS Catalina NAS NFS shares was quite simple, once I got the right information. Configuration files.

/etc/auto_master:

#
# Automounter master map
#
# Literal mount point for filesystems described in "auto_resources"
#
/System/Volumes/Data/Volumes auto_resources
+auto_master		# Use directory service
    ... the rest is just boiler plate...

/etc/auto resources:

share1 -fstype=nfs,resvport,locallocks,soft,intr,rw,rsize=16384,wsize=16384,fnc 192.168.10.12:/mnt/share1
share2 -fstype=nfs,resvport,locallocks,soft,intr,rw,rsize=16384,wsize=16384,fnc 192.168.10.12:/mnt/share2

Afterwards: sudo automount -vc

One point: Make sure you can manually mount your NFS shares, and have proper access to the mounted filesystem before configuring automount.

@dmlane

This comment has been minimized.

Copy link

@dmlane dmlane commented Aug 23, 2020

Does anyone have a solution to /etc/auto_master being overwritten on Catalina updates>

@Michelasso

This comment has been minimized.

Copy link

@Michelasso Michelasso commented Aug 23, 2020

Does anyone have a solution to /etc/auto_master being overwritten on Catalina updates>

Make a copy and copy it over the new /etc/auto_master after each update. Or restore it from a backup (Time Machine or else) after the update. That's what I used to do, nothing automatic I'm afraid.

@dmlane

This comment has been minimized.

Copy link

@dmlane dmlane commented Aug 24, 2020

Does anyone have a solution to /etc/auto_master being overwritten on Catalina updates>

Make a copy and copy it over the new /etc/auto_master after each update. Or restore it from a backup (Time Machine or else) after the update. That's what I used to do, nothing automatic I'm afraid.

Thanks - that's what I do, but it's really annoying if there's an automatic update while I'm away as I have some jobs which will fail.
Debian has a autofs.master.d folder which allows custom config to be included which doesn't get clobbered - it's a shame there's nothing similar on Catalina.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.