On 21 Feb 2023, at 11:52, Florian Möller wrote: > Hi Benjamin, > > here are the trace and a listing of the corresponding network packages. If the listing is not detailed enough, I can send you a full package dump tomorrow. > > The command I used was > > touch test.txt && sleep 2 && touch test.txt > > test.txt did not exist previously. So you have an example of a touch without and with delay. Thanks! These are great - I can see from them that the client is indeed waiting in the stateid update mechanism because the server has returned NFS4ERR_STALE to the client's first CLOSE. That is unusual. The server is signaling that the open file's stateid is old, so I am interested to see if the first CLOSE is sent with the stateid's sequence that was returned from the server. I could probably see this if I had the server-side tracepoint data. But from what's here I cannot see the details to figure this out because you've only sent the summary of the packet capture.. can you send along the raw capture? I usually use something like: tshark -w /tmp/pcap -i enps0 -P host server .. then the file /tmp/pcap has the raw capture. We can use that to look at the sequence numbers for the stateid as sent from client to server. However, if you use krb5p, we won't be able to see these details. Only krb5 or krb5i. If the problem only reproduces with krb5p, we have to rely on the tracepoints output on the client and server. Ben