Dumb NAS: It works as NAS and NAS only, no Docker, no VM, no Apps, only as a NAS before an offsite backup scripts kicks in.
I run Proxmox and only it will run LXC containers and what not.

CONTEXT:

Hi all,

I got my unRaid up and running, after some permissions drama, I got a NFS shared called htpc set as:

10.19.0.9(rw,sync,no_subtree_check,insecure,no_root_squash)

That means that only that Proxmox server has access to /etc/pve/htpc/, nobody else.
To keep things simple, It was mounted on Proxmox like so:

10.19.0.12:/mnt/user/htpc/ /mnt/pve/htpc/ nfs defaults 0 0

PROBLEM:

The first thing I did was to move Jellyfin/qBittorrent files from Proxmox to unRaid via rsync.

Everything was working, I can see unRaid doing its thing but since I am on 1G network, it is taking forever.

Regardless, I try to see how things were going and the folder was displayed like so:

d????????? ? ? ? ? ? htpc

It seems like unRaid NFS connections drops when transferring bulk data, we are talking about ~800GB of data.

One of the solution was to avoid NVMe cache and save to the Array instead. I am not very please with that "solution".

How are folks with the same setup as me doing this??

It seems like I am gonna have to leave everything locally on Proxmox, and run a rsync script to sync things over once here and there.

That breaks the purpose of NAS.

Thanks a lot for any help.

There is some shenanigans going on.

The log shows:

Mar 7 21:37:31 NAS rc.nfsd: /usr/sbin/exportfs -au

Mar 7 21:37:31 NAS rc.nfsd: NFS server daemon... Stopped.

Mar 7 21:37:32 NAS rc.nfsd: Starting NFS server daemon...

Mar 7 21:37:32 NAS rc.nfsd: /usr/sbin/exportfs -r

Mar 7 21:37:32 NAS rc.nfsd: /usr/sbin/rpc.nfsd -u -H 10.19.0.12 -H 127.0.0.1 -s 8

Mar 7 21:37:33 NAS kernel: NFSD: Using UMH upcall client tracking operations.

Mar 7 21:37:33 NAS kernel: NFSD: Using UMH upcall client tracking operations.

Mar 7 21:37:33 NAS kernel: NFSD: starting 90-second grace period (net f0000000)

Mar 7 21:37:33 NAS rc.nfsd: /usr/sbin/rpc.mountd

Mar 7 21:37:33 NAS rpc.mountd[281417]: Version 2.8.4 starting

Mar 7 21:37:33 NAS rc.nfsd: NFS server daemon... Started.

Mar 7 21:39:20 NAS rpc.mountd[281417]: authenticated unmount request from 10.19.0.9:858 for /mnt/user/htpc (/mnt/user/htpc)

The NFS daemon is indeed stopping for whatever reason.

I have made some minor changes:

#Unraid

10.19.0.12:/mnt/user/htpc/ /mnt/pve/htpc/ nfs rw,vers=4.1,hard,noatime,rsize=1048576,wsize=1048576,timeo=600,retrans=5,nconnect=8 0 0

So far the NFS shared folder hasn't died again for idk 30 minutes when it was dying under 5 minutes.

But I do not trust using unRaid for the LXC storage, I mean, I cannot afford qBittorrent crashing with private tracker.

I am forced to keep things locally and use a rsync script to sync things over to unRaid on the background.
If problems happens, I do not care if things break under those circumstances, better than having qbittorrent. radarr, sonarr, jellyfin processes that is fully automated right now crashing.

I am curious to hear how folks are solving these annoyances.

I spoke too soon, it died again.
So unRaid does not work with Proxmox, you are forced to run its own docker stuff

Every 2.0s: ls -lah /mnt/pve/

ls: cannot access '/mnt/pve/htpc': Stale file handle

total 12K

drwxr-xr-x 5 root root 4.0K Mar 8 11:17 .

drwxr-xr-x 3 root root 4.0K Jan 12 21:07 ..

d????????? ? ? ? ? ? htpc

drwxr-xr-x 8 root root 91 Feb 14 19:35 jellyfin

drwxr-xr-x 9 root root 4.0K Feb 14 23:13 recording

Sooooo, you cannot use NVMe cache with unRaid, you are forced to use Array only of NFS/SMB stops working making it virtually impossible to use with Proxmox.

unRaid is heavily designed with the idea of you must run apps via its own Docker stuff using the local /mnt/user<shared_folder> so if you are heavily Proxmox user, your are RIP.

idk what to feel about it.

Is the share you are trying to use at the Unraid end set to be ‘cached’ (I.e. it has both primary and secondary storage set in the Unraid settings for the share)? I have seen regular reports that this can lead to ‘stale file handle’ reports happening after ‘mover’ runs with shares being accessed via NFS. I am not a NFS user myself, but it is apparently an inherent problem due to the way NFS tracks files.

The way to avoid this issue is to either not have the share not set to be cached (I.e. no Secondary storage set for the share at the Unraid level), or to use SMB sharing instead.

Whether this your actual problem I am not sure. You may get better informed feedback if you attach your Unraid system’s diagnostics (with everything in the one zip file) to your next post in this thread. Also mention the name of the share being used. It is always a good idea when asking questions to supply your diagnostics so we can see details of your system, how you have things configured, and the current syslog.

NFS should not be used with primary and secondary storage, only with primary storage, and use exclusive shares if it's a pool, since it uses the inodes to track the files, and those will change if the files get moved to different storage, causing stale file errors.

2 hours ago, itimpi said:

Is the share you are trying to use at the Unraid end set to be ‘cached’ (I.e. it has both primary and secondary storage set in the Unraid settings for the share)? I have seen regular reports that this can lead to ‘stale file handle’ reports happening after ‘mover’ runs with shares being accessed via NFS. I am not a NFS user myself, but it is apparently an inherent problem due to the way NFS tracks files.

The way to avoid this issue is to either not have the share not set to be cached (I.e. no Secondary storage set for the share at the Unraid level), or to use SMB sharing instead.

Whether this your actual problem I am not sure. You may get better informed feedback if you attach your Unraid system’s diagnostics (with everything in the one zip file) to your next post in this thread. Also mention the name of the share being used. It is always a good idea when asking questions to supply your diagnostics so we can see details of your system, how you have things configured, and the current syslog.

I am not a NFS specialist either haha

I run Linux only and it is a lot easier than SMB when it comes to permissions.
The "solution" seems to be indeed to remove the cache, it has not died, yet, but I got trust issue.

As it is, I am forced to keep using local SSD and leave a bunch of rsync scripts copying things over, if they fail so be it.
I confess that I am not please I cannot use the 500GB NVMe cache.

NAS is a NAS, Proxmox is Proxmox.
I dislike Docker very much and manage everything as infrastructure as code via Ansible without any dramas, it is beautiful.
I am not using Docker just to have caching.

54 minutes ago, JorgeB said:

NFS should not be used with primary and secondary storage, only with primary storage, and use exclusive shares if it's a pool, since it uses the inodes to track the files, and those will change if the files get moved to different storage, causing stale file errors.

This appears to be an unRaid ongoing problem tho, posts go back to "201X", 2025 posts with folks having problems.

Mind you, you don't need to move files for it to crash, just mount it, go grab a coffee and voila, it crashed.
I did try SMB over NFS and it crashed even faster.

When it does crash while rsync is running, rsync can still copy files over and unRaid still going but the folder is gone.

It must be remounted and LXC containers restarted.

800GB took me an entire day to copy over which is insane, I won't be writing that much data, just this whole friction to get a simple NFS share working, wasted an entire Sunday.

Thank you so much all, at least now I have insights of what is going on, and see what to do next.

Cheers