0

I am having a problem with mounting an NFS share from my Western Digital server to my Raspberry Pi. As a relatively inexperienced Raspberry user, I solicited help from several collaborators and ultimately I learned that NFS was the best way to interface with the server. In addition, we learned that rpcbind needed to be running for the mount to proceed. With their help, after creating an nas folder within my pi folder, I was able to insert the following lines in my crontab file:

@reboot sudo /etc/init.d/rpcbind start

@reboot sudo mount -t nfs 192.168.1.152:/nfs/Music /home/pi/nas

@reboot /usr/bin/asset/bin/AssetUPnP

This script actually worked quite well for a while. Unfortunately, I now find that the mount no longer occurs automatically, despite my being sure the server is awake and can be accessed before starting the Raspberry Pi. Of interest, I do find that the AssetUPnP program does open.

More confusing, however, is that following the unsuccessful mount, if I then access the Raspberry Pi directly via terminal and manually enter the first two lines in sequence, they work perfectly, the share mounts and then the -- already running -- AssetUPnP program can access the mounted share. Thus, I believe the scripts seem to be properly composed. Might anyone have any suggestions about what might be going on here? Do I need to program in some kind of delay between the first and second line? Am I missing something else? Any help would be greatly appreciated.

  • Do you have a version of Raspbian with systemd? – Jaromanda X Jul 15 '18 at 23:22
  • At the very least you should start rpcbindwith a systemd service. It SHOULD be started if installed systemctl status rpcbind` will show if it is running. Trying to run SysV commands from crontab is STRANGE to say the least! You would be better mounting in fstab – Milliways Jul 16 '18 at 2:41
1

There is some curious with your installation to start nfs. My answer is valid for Raspbian Stretch, don't know what you are using.

On modern operating systems there is cron managed by systemd. Check with systemctl status cron. man 5 crontab says:

Please note that startup, as far as @reboot is concerned, is the time when the cron(8) daemon startup. In particular, it may be before some system daemons, or other facilities, were startup. This is due to the boot order sequence of the machine.

With systemd services (daemons) are started parallel and the order is undefined. So @reboot will work for a long time but suddenly fails because an edge condition has changed by updating or installing or reconfiguring another service that changed boot order. There are some questions here on this site having this problem.

Mounting remote nfs shares is done by nfs-common. This is installed by default:

rpi ~$ apt list nfs-common
Listing... Done
nfs-common/stable,now 1:1.3.4-2.1 armhf [installed]

I don't know if you are using NFSv3 or NFSv4 but if required you can configure specific settings in /etc/default/nfs-common. There is no need to start rpcbind by hand. It's done by the service if needed.

As customary then you mount to nfs shares with entries in /etc/fstab. This line in your /etc/fstab should do it:

192.168.1.152:/nfs/Music   /home/pi/nas   nfs   _netdev,auto   0   0

The program AssetUPnP should you start with a systemd unit.

0

You might want to try enabling Wait for Network in raspi-config. See this for instructions: https://github.com/legotheboss/YouTube-files/wiki/(RPi)-Wait-For-Network-at-Boot

  • We're looking for long answers that provide some explanation and context. Don't just give a one-line answer only with a link; explain why your answer is right, ideally with citations. Answers that don't include explanations may be removed or you risk to get down votes. Please take the short Tour and visit the Help Center to get an idea how things work here. – Ingo Jun 30 at 0:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.