Western Digital Music Share suddenly won't mount to Raspberry Pi

[ASF]

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:

Attachment 2122

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.

Attachment 2123

I really need some help sorting this out.

Thanks

Aaron

[ASF]

I am pleased to advise that I resolved the problem this morning!!! I found a document indicating that the only changes to the server with the firmware update involved changes relating to the EU privacy regulations. This fact suggested that some basic settings on the server had been returned to a default setting, thereby preventing the share from mounting. I went through all of the settings and noted that the sleep mode was set to initiate after ten minutes (not sure if this was how it was set previously) which I increased to 30 minutes. When I rebooted the Raspberry Pi, the Music share mounted using the revised mount command 192.168.1.152:/nfs/Music /home/pi/nas nfs ro 0 0. I suppose I could now change it back to the command with "nfs://" at the front to discern whether the issue is the revised command syntax, the prolonged delay before sleep mode or both, but I think I will leave that for another day!