I originally installed Asset UPnP on a Western Digital Sentinel NAS as my media service. After several years, the LCD on the server failed requiring that I replace it with the PR4100 which does not support Asset UPnP. To address this problem, Simon helped me set up a Raspberry Pi to run the Asset program and develop the appropriate code for the Raspberry Pi to mount the Music Share using NFS.
Last weekend, I upgraded the firmware on the WD server and suddenly find that the mount fails. I have been unable to obtain a resolution yet from either Western Digital and need help.
The server is configured for NFS with the following mount point: nfs://192.168.1.152/nfs/Music.
The added programming in the Raspberry Pi included the following line in my "/etc/fstab" file:
nfs://192.168.1.152/nfs/Music /home/pi/nas nfs ro 0 0.
In addition, we added the following lines to my "/etc/crontab" file:
@reboot /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
With these changes, the system worked quite well for nearly a year, but suddenly after the server firmware update, the Music Share will no longer mount. When I run "ls -l" or "sudo mount -a" in the "/home/pi/nas" folder, I receive the following message:
I posted this information as a reply to another thread which seemed to mention the same problem. I opted to start a new thread since there was no response.
I also posted this issue on a Linux forum (Stack Exchange) where someone suggested deleting "nfs://: at the start of the mount command in /etc/fstab. I changed the mount command to:
192.168.1.152:/nfs/Music /home/pi/nas nfs ro 0 0.
This generated the following message: mount.nfs: rpc.statd is not running but is required for remote locking. Either use '-o nolock' to keep locks local, or start statd. An incorrect mount option was specified. I then tried the following syntax for the mount command:
192.168.1.152:/nfs/Music /home/pi/nas nfs ro -o nolock 0 0 but I got a syntax error with the same issue about locking.
I would note that I found a way to check the Raspberry's status regarding NFS by seeking to upgrade "NFS-common". As per the image below, all seems in order, further confusing me as to why I got the original message about NFS URLs not being supported.
I really need some help sorting this out.
Thanks
Aaron
Last weekend, I upgraded the firmware on the WD server and suddenly find that the mount fails. I have been unable to obtain a resolution yet from either Western Digital and need help.
The server is configured for NFS with the following mount point: nfs://192.168.1.152/nfs/Music.
The added programming in the Raspberry Pi included the following line in my "/etc/fstab" file:
nfs://192.168.1.152/nfs/Music /home/pi/nas nfs ro 0 0.
In addition, we added the following lines to my "/etc/crontab" file:
@reboot /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
With these changes, the system worked quite well for nearly a year, but suddenly after the server firmware update, the Music Share will no longer mount. When I run "ls -l" or "sudo mount -a" in the "/home/pi/nas" folder, I receive the following message:
I posted this information as a reply to another thread which seemed to mention the same problem. I opted to start a new thread since there was no response.
I also posted this issue on a Linux forum (Stack Exchange) where someone suggested deleting "nfs://: at the start of the mount command in /etc/fstab. I changed the mount command to:
192.168.1.152:/nfs/Music /home/pi/nas nfs ro 0 0.
This generated the following message: mount.nfs: rpc.statd is not running but is required for remote locking. Either use '-o nolock' to keep locks local, or start statd. An incorrect mount option was specified. I then tried the following syntax for the mount command:
192.168.1.152:/nfs/Music /home/pi/nas nfs ro -o nolock 0 0 but I got a syntax error with the same issue about locking.
I would note that I found a way to check the Raspberry's status regarding NFS by seeking to upgrade "NFS-common". As per the image below, all seems in order, further confusing me as to why I got the original message about NFS URLs not being supported.
I really need some help sorting this out.
Thanks
Aaron
Comment