Reliably mounting NFS filesystems before Octoprint starts


#1

TLDR: If your network supports both IPV4 and IPV6, add

waitip 4 6

to the end of your /etc/dhcpcd.conf file to ensure that you receive both an IPV4 and IPV6 address before NFS mounts occur.

What is the problem?

I wanted to use another system (much faster than my Raspberry Pi running Octopi/Octoprint) on my network to render timelapses. To help accomplish that, I have an NFS share on that system that I mount on my RPi and tell Octoprint to use that filesystem to store timelapses, and then tell Octoprint to call a shell script that does an ssh to the remote machine to actually do the render.

This works fine except for the fact that I was having great difficulty getting the filesystem to mount reliably before Octoprint starts. If the filesystem is not mounted before Octoprint starts, Octoprint resets the timelapse location configuration to the default and the whole house of cards collapses.

What did you already try to solve it?

My first attempt was just to add the NFS filesystem to fstab so it would mount normally. No dice - it would not automount when the RPi was booted and I had to manually run "mount /var/space".

After googling, I managed to get this to seemingly work reliably (on OctoPi 0.15.0) by using the following line in /etc/fstab:

10.128.1.14:/export/space /var/space nfs rw,soft,noauto,x-systemd.automount 0 0

However, after a flaky SD card caused me to have to reinstall OctoPi from scratch (upgrading to 0.15.1) this stopped working. I've tried adding $remote_fs to the Required Start: line in /etc/init.d/octoprint so that Octoprint doesn't start until all remote filesystems are mounted, but no dice. It seems like systemd tries to mount the filesystem before all requirements for NFS mounting are met, and gives up when the mount failed.

I finally resorted to adding

sleep 15
mount /var/space

to the beginning of /etc/init.d/octoprint and that seemed to do the trick, but I wanted to do this in a cleaner way.

Finally, I remembered an issue I had on one of my other systems. MySQL on that system would fail to start up because there was no IPV4 address, since dhcpcd would return as soon as it had the IPV6 address that would be assigned first. The fix for that is to add:

waitip 4 6

to the end of the /etc/dhcpcd.conf file so that both addresses need to be acquired before dhcpcd returns.

With that fix, I no longer needed the x-systemd.automount in fstab, leaving me with the following entry in /etc/fstab:

10.128.1.14:/export/space /var/space nfs auto,rw,soft 0 0

#2

I came at that a different way. USB drives are so cheap now that I've added one to the RPi. Putting the swap area on the USB drive also speeds up the RPi greatly once it starts hitting swap.


#3

The main purpose of using NFS wasn't to get more space, but rather to move the timelapse files to a server with more CPU grunt so I could render timelapses as MP4 without completely bogging down the RPi.
I've configured Octoprint to run a shell script to render timelapses that does an ssh to the remote server to run a python script that massages the rendering command line to change the parameters needed to render to MP4 and calls ffmpeg to do the actual remote rendering.