Search code examples
macosnfs

NFS mount keep changing inode


I'm using a MacBook Pro with Catalina for all my development. I also run a VM with ubuntu 16.04 through virtualbox where I export a NFS share. The export looks like this:

/export/dev 192.168.0.0/16(rw,insecure,no_subtree_check,async,all_squash,anonuid=1000,anongid=1000)

and I mount this on my Mac with

mount -o rw,nolocks,locallocks -t nfs 192.168.56.102:/export/dev /Users/myhome/Documents/dev

nfsstat -m is saying

NFS parameters: vers=3,tcp,port=2049,nomntudp,hard,nointr,noresvport,negnamecache,callumnt,locallocks,quota,rsize=32768,wsize=32768,readahead=16,dsize=4096,rdirplus,nodumbtimr,timeo=10,maxgroups=16,acregmin=5,acregmax=60,acdirmin=5,acdirmax=60,nomutejukebox,nonfc,sec=sys

most of the time everything is working, but more and more often I get strange errors and folders in sublime text starts to look like folders with "link" on. Investigating that in the console, I get errors saying that the inodes has already been seen and the folder is considered a symbolic link in sublime.

I investigated this further and do not think this is a sublime error, but more likely a MacOS problem. When everything is working and I write ls -i in Mac OS in one of my mounted folders I get the exakt same inode results as on the VM. But 5 minutes later doing the exact same thing - I get totally different inodes and the exact same inode numbers on all files in the same folder.

Has anyone experienced this before? Is this a NFS parameter issue? I have googled this and haven't found anything on the internet about anyone with similar problems.


Solution

  • You are right. I'm seeing the exact problem on Catalina 10.15.7. The workaround I have for now is to specify actimeo=0. With the default actimeo=60, files/dirs attributes are refreshed periodically every 60s. Inode numbers are initially correct immediately following the mount, but each refresh changes files within the same directory to have an identical and seemingly random inode number. This is bad as hell, as it breaks the fundamental assumption of a lot of programs, including dyld, which uses inode number to identify loaded images internally. (function bool ImageLoader::statMatch(const struct stat& stat_buf) const from https://opensource.apple.com/source/dyld/dyld-750.6/src/ImageLoader.cpp.auto.html). I'm trying to file a bug report to Apple and see how to move forward.

    Update 1: I quote the answer from Apple:

    After reviewing your feedback, we have some additional information for you, or some additional information, or action is necessary for this issue: To work around the issue, mounting with nordirplus should fix this. Also, the issue is resolved in macOS Big Sur (11+) so, you could try that as well.