There is some curious on 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.

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.

There is some curious on 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

There is some curious on 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.