NFS with Docker on macOS Catalina

NFS With Docker on macOS Catalina

You like living on the edge, life is fun on the edge until the edge is a macOS major update. Then you use vibrantly colorful words, some that your dead ancestors heard, all because your development environment now doesn’t work in spectacular fashion.

This was me this afternoon at about 12:33pm, when I discovered that macOS has moved all of the User data to new volumes, and that our docker setup for NFS now gave us this wonderful error when I tried to start the app:

ERROR: for exporter Cannot create container for service exporter: failed to mount local volume: mount ://Users/Bobby/Documents/firehydrant/laddertruck:/var/lib/docker/volumes/laddertruck\_nfsmount/\_data, data: addr=192.168.65.2,nolock,hard,nointr,nfsvers=3: permission denied

We use NFS with Docker For Mac because of the superior read speeds (something necessary when working with Rails applications like we do). It works great… most of the time. It’s based on this great blog post: Set Up Docker For Mac with Native NFS.

NFS uses a /etc/exports file that maps out how a directory is exported to remote hosts. Previously, this file had this contents:

/Users -alldirs -mapall=501:20 localhost

Well, if you’ve updated to macOS Catalina as I did, this will give you the permission error we saw above. You need to mount the new volume that contains User data:

/System/Volumes/Data -alldirs -mapall=501:20 localhost

Great, so now, in our docker-compose.yml file where we use the NFS mount, we also need to make a change to attempt to mount this new directory. Since I am in the /Users/bobbytables directory, this works well as a suffix to the /System/Volumes/Data/ pathing.

volumes:
 nfsmount:
 driver: local
 driver\_opts:
 type: nfs
 o: addr=host.docker.internal,rw,nolock,hard,nointr,nfsvers=3
 device: ":/System/Volumes/Data/${PWD}"

Once you're done, you'll need to restart nfsd:

sudo nfsd restart

Great. Now I can boot my app again!🎉 Unfortunately, not all of our engineers were successful. Some of us kept our codebase in ~/Documents and the new permissions-based access control in Catalina prevents nfsd from accessing those directories. All other apps you use will prompt for permission but as nfsd isn't running as your own user, it won't trigger the prompt.

Our original fix was just to move the codebase out of a protected directory but thankfully @randyfay pointed us towards an issue on the Vagrant issue tracker with a fix.

Twitter

With these fixes our engineers are able to upgrade to Catalina without moving their codebase around.

You just got paged. Now what?

FireHydrant helps every team master incident response with straightforward processes that build trust and make communication easy.

Learn How