Strange NFS client behavior


Since a few days, I’ve noticed a strange and abnormal behavior on my machine with Leap 15.4 as a NFS client. This behavior is new, although I did not change my configuration. Furthermore, I do not see this behavior on another Leap 15.4 machine, also acting as NFS client, and a priori configured the same way.

In an NFS share, if I create a file or a directory, it is not listed in the subsequent ls, but it seems nevertheless to be created (also checked to be present on the NFS server’s physical media).

> mkdir test
> echo "Test" > test.txt
> ls
(no mention of test or test.txt)
> mkdir test
mkdir: cannot create directory ‘test’: File exists

Also, if I move an existing file to a directory, the NFS client does not seem to track this move correctly (although it is correctly moved on the NFS server’s physical media).

> mv myfile.jpg directory/
> ls -l
-????????? ? ?      ?           ?            ? myfile.jpg
> mv directory/myfile.jpg .
(the file is correctly back)

Any idea what could be causing this?

Thanks & kind regards,

PS: If it helps, here is how the NFS share is mounted: on /media/RG type nfs4 (rw,relatime,vers=4.2,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=,local_lock=none,addr=,_netdev)

Are both systems using the same exported resources from the same NFS server?

Yes, and using the same options.

The only difference is that this other system is a bit behind in terms of updates. I’ll do the update to see if it is significant.

I let the updates install, unchanged situation: strange behavior on my main system, fine behavior on the other system.

Worst case, I’ll redo a fresh installation… :grinning:

we can confirm the issue with kernel 5.14.21-150400.24.49.
The issue wasn’t there in kernel version 5.14.21-150400.24.41 and 5.14.21-150400.24.46. So the issue was introduced after 5.14.21-150400.24.46.

This seems to be an issue with nfs caching. After issuing “echo 3 > /proc/sys/vm/drop_caches” the files are listed correctly (unfortunately this is of course no permanent solution - just a proof that it has to do something with caching).



1 Like

You have to open bug report. Kernel 49 was retracted due to other serious issues, so it is the perfect time to make sure this bug is also fixed before next update.

There is already a Bugzilla issue for this: Bug 1209457 – NFSv4 broken after kernel update (5.14.21-150400.24.46-default to 5.14.21-150400.24.49)

1 Like

Thanks for everyone’s feedback! Indeed, the machine that has the problem has kernel .49, whereas the other machine (w/o the problem) has kernel .46.

I can confirm same behaviour on my nfs client machine. I have installed .49 and .38 kernel, if I boot with .38 the problem stop. As the problem is solved but the kernel patch is still not in the opensuse repos I will keep using .38 kernel for some days.

Thanks to all

I have just update to 5.14.21-150400.24.55-default, the problem is fixed in the new kernel.

I confirm that since the move to kernel version .55, the problem is gone on my machine. Thanks to all!