Join GitHub today
NFS mount to WinNFSd stops working after about 15-30 minutes #68
I'm running Windows 10 and WinNFSd 2.4.0.
I start WinNFSd in the foreground with:
The content of nfs-pathfile.txt:
From my Minikube VM I create an NFS mount with:
At this point, it works great! I can list, read and write files. The WinNFSd program logs all kind of file access very fast.
However after about 15-30 minutes, if I do a
I disabled all sleep / energy settings, also the disks are never turned off. But I still get this problem. Do you have any idea what goes wrong? Or what options there are left to try?
Do others have WinNFSd running fine for at least a couple of days?
I have exactly the same problem using the same setup (minikube on windows). I've found after 15-30 minutes of idle when I try to access the NFS share it hangs. Sometimes it comes back in a few seconds, sometimes it takes close to a minute, and a couple times it completely froze and I had to kill minikube.
I tried switching to udp and so far I haven't experienced the problem, but surprised there aren't more people complaining about this issue.
You two are definitely not the first to complain about problems with TCP. For example:
At this point, it might be helpful to use a tool like Process Explorer to examine the hung thread and see if it reveals any clues, such as a specific procedure call, ballooning resource consumption over time, etc.
Also, @pietervogelaar , I would edit the Issue title to include Minikube, as this problem seems to be specific to its use.
@pietervogelaar Have you confirmed that, or are you speculating?
I'm not saying you're wrong, I just don't want to waste anybody's time trying to reproduce the issue when, last we knew, all of the "TCP hanging" issues were effectively ironed-out.
The fact that nobody has mentioned issues with TCP in quite some time, excepting two Minikube users, makes the question relevant, IMO.
Just to add a bit more color: for me, MiniKube is running inside a VirtualBox VM.
@cbj4074's point is valid. I have not tried to reproduce this issue on a non-MiniKube VM, so it's possible it is directly related to MiniKube.