Remote file system

I'm trying to have service work against a remote file system. I'm running the service on Linux, so the obvious choice was NFS, but I've noticed that if I reboot the NAS service, I will lose everything and then take a very long time to re-add everything.

I thought I'd try SMB and UNC paths as I hoped it would have a bit more intelligence around an unavailable endpoint being distinctly different from an empty one, but I can't seem to enter UNC paths into the console. When I save my settings, it prepends a /, suggesting it's trying to find a local directory.

Does anybody have a reliable method to deal with remote file systems?

I had the same issue at bootup after power losses, so I changed somthing on my Linux system. Basically, it was taking too long to mount the nfs share from my NAS before the Serviio service loaded. So I fixed it using the following configuration changes.

1. Remove the NAS share mount from the fstab. (I decided to use a command in a script instead.) Then saved the file and updated grub.

2. Disabled the Serviio service. (Again, script...)

3. Created a file at /etc/rc.local and ran "chmod +x" on it to allow for execution. (The linux kernel tries to run the file for backwards compatibility at startup. It was a common way to do startups prior to 2012 or so.)

4. I put the following information in the file using nano: (The sleep commands are delays to allow the NAS to complete booting and the rest of the startups to run prior to execution. The nfs is v3, and behind a firewall, so it doesn't require a username or password.)

#!/bin/sh -e

sleep 10s

mount -t nfs 192.168.250.250:/volume1/public/ /media/public/

sleep 15s

/opt/serviio/bin/serviio.sh

exit


4. Created a file at /usr/sbin/serviiostop, and ran "chmod +x" on it to make it executable.

5. Put the following information in the file using nano:

#!/bin/sh -e

/opt/serviio/bin/serviio.sh -stop

exit

6. Created a file at /usr/sbin/serviiostart, and ran "chmod +x" on it to make it executable.

7. Put the following information in the file using nano:

#!/bin/sh -e

/opt/serviio/bin/serviio.sh

exit

As a result, Serviio is now no longer a service, but still starts at reboot after my nfs mounts. I can restart Seriio by running "serviiostop && serviiostart".

You can also, obviously, script your nfs mounts for when you restart your NAS and need to umount/mount your nfs. NFS v3 will usually attempt a remount when disconnected/reconnected. NFS v4 usually will not because it requires a key (if configured) or username and password at mount. In that case your restart Serviio command after NAS restart would be something like "serviiostop && nfsumountmountscript && serviiostart".

The nfs umount/mount script would probably look soomething like this (depending on your nfs settings, and add sleep commands for delays between commands if necessary). (You need to use chmod +x to mark it as an executable script. If you put it in a pathed directory like /usr/sbin you can run the command directly without having to reference it by the full path.)

#!/bin/sh -e

umount -R -f /media/public

sleep 15s

mount -t nfs 192.168.250.250:/volume1/public/ /media/public/

exit

My Serviio has been rock solid over NFS, with near instant access/playback. So once you have the settings right (and it may take some tweaking), I believe you should have the same.

If you are dead-set on migrating away from NFS another great option is using anonymous FTP on the NAS if it is behind a firewall, and using curlftpfs to mount the files on your Linux machine... Seems to also be faster than using SMB on my Synology NAS.

Hopefully this helps.