So I had a 2nd unraid server connected through UD as an NFS share. I used this share to backup my appdata using duplicacy. I came home today to find that the connected unraid server had crashed. Duplicacy showed it had been attempting to upload the backup for several hours without progress. So my first port of call was to try stop the duplicacy container... this failed in the normal gui way.. eventually i was able to forcestop it. Grand but I was seeing a persistent "kernel: nfs: server 192.168.1.50 not responding, timed out" in the logs. So I then tried to stop the nfs service... in settings when I changed the setting to No and tried to click apply nothing happened. So again I force stopped the service using "/usr/local/etc/rc.d/rc.nfsd stop" command. I got notified that the service had stopped and the logs also reflected this. Still the nfs timeout warning continued to appear. So i have tried to stop the array and the docker service appears to have stopped successfully however the array will not stop. Also a shutdown doesnt do anything and I continue to get the nfs timeout issue. Not really too sure where to go from here. I havent hard reset the server yet just in case there is something I can do. Any help would be greatly appreciated. Even just to get the server shut down gracefully.

server-diagnostics-20260811-1855.zip

***EDIT***

Ok so when I got my 2nd server back up and running... Hard reset its not as vital for me... the server shut down gracefully. But I guess the issue still stands when this instance occurs and I'm not in a position to hard reset the mounted drives what is the best course of action to get to a place to rectify it?

Edited 15 hours ago15 hr by tazire

The diagnostics confirm that the remote NFS server became unavailable while Duplicacy had active writes on a hard NFS mount. With a hard mount, the Linux NFS client continues retrying indefinitely; the “timed out” messages do not mean that the requests have been abandoned.

Unassigned Devices later performed a lazy unmount, which removed the visible mountpoint but did not cancel the outstanding NFS requests. Array stop subsequently became blocked at the global filesystem sync, and both the sync and shutdown processes are now in uninterruptible sleep.

Stopping the local NFS service will not affect this because that service controls exports from this server, not its client connection to the other server.

If possible, the safest recovery is to bring the remote server back online at the same address and export path. If that cannot be done, a clean shutdown may no longer be possible and a forced reboot may be required.

After recovery, also recomemnd correcting the Fix Common Problems warning that the Duplicacy Unassigned Devices path is not mounted with slave propagation.

2 hours ago, JorgeB said:

The diagnostics confirm that the remote NFS server became unavailable while Duplicacy had active writes on a hard NFS mount. With a hard mount, the Linux NFS client continues retrying indefinitely; the “timed out” messages do not mean that the requests have been abandoned.

Unassigned Devices later performed a lazy unmount, which removed the visible mountpoint but did not cancel the outstanding NFS requests. Array stop subsequently became blocked at the global filesystem sync, and both the sync and shutdown processes are now in uninterruptible sleep.

Stopping the local NFS service will not affect this because that service controls exports from this server, not its client connection to the other server.

If possible, the safest recovery is to bring the remote server back online at the same address and export path. If that cannot be done, a clean shutdown may no longer be possible and a forced reboot may be required.

After recovery, also recomemnd correcting the Fix Common Problems warning that the Duplicacy Unassigned Devices path is not mounted with slave propagation.

Thanks for explaining all that. That helps. I have the 2nd server setup with a static ip. So once I got that back online it did rectify the issue and my main shut down gracefully as expected.

Is there anyway to mitigate this type of issue in future? I dont want my 2nd server crashing to cause such issues on my main if I can avoid it. I understand it will obviously cause some issues but can I set it up such that when I stop the nfs service it fully stops all persistent requests? Is it a hard vs soft mount difference? Also is the hard vs soft mount something I can configure in UD?

Yes, this is related to hard versus soft NFS mounts. Unassigned Devices currently mounts NFS remote shares as hard mounts and does not provide a hard/soft option AFAIK.

Disabling NFS under Settings only stops shares exported by this server. It does not stop the NFS client or cancel requests already waiting on the remote server.

Although a soft mount would eventually return an error, it is not generally recommended for a backup destination because interrupted operations can result in data corruption.

To avoid this particular failure mode, best bet would be to configure Duplicacy to connect directly to the second server using a different protocol instead of accessing it through an NFS mount, if that's a possibility, e.g., SFTP if supported. Also correct the container mapping to use RW:Slave; that will ensure mount changes propagate into the container, although it cannot cancel requests already blocked in the NFS client.

For planned maintenance, stop Duplicacy and unmount the UD share before shutting down the second server. If the remote server crashes during an active hard-mount write, bringing it

back at the same address remains the safest recovery.