No "parallel access" to NFS share hosted on Raspberry

It seems I can't have a "parallel access" to the file system that is hosted on my Raspberry PI.

Here's my setup:

NFS Server:

• Raspberry Pi 4 with Debian GNU/Linux 11 (bullseye).
• /etc/exports: /mnt/DataBackupNAS *(rw,async,no_root_squash,no_subtree_check)

NFS Client:

• Desktop with Ubuntu Jammy Jellyfish.
• /etc/fstab: raspberrypi:/mnt/DataBackupNAS /media/laurent/DataBackupNAS nfs noatime,_netdev,nofail,nolock,async

Steps to reproduce:

1. Copy a large file from NFS client to Raspberry.
2. Before the copy finishes, try to browse to another directory with Nautilus or "ls" a directory from command line.

Expected: The directory is listed.

Observed: "ls" command is stuck. Nautilus spins in a waiting state until the copy is finished.

Notes:

• Windows guest seems OK : I can browse the Raspberry NAS and even "cross-copy" big files at the same time. Everything is responsive. So the problems seems more Ubuntu / mount options related.
• Doing a "ls" through SSH on the Raspberry itself works during the copy.
• I've already tried these things with no success so far:
  • Set async modes on server and client. "async" should be the best option as the NFS documentation states that operations are performed sequentially in "sync" mode ?
  • Increase rsize and wsize on client.
  • Increase RPCNFSDCOUNT to 16 instead of 8 on server.

Appart from that, everything works fine. The copy operation is quite fast and reliable compared to my Internet provider NAS, it's just that I can't do anything else on the server before the copy is finished.

Edit: The Raspberry remains quite responsive when I SSH into it and do some ls or even internal copy operations while the "big file" copy is running.

rpcnfsdcount is a server side parameter that defines the number of threads dedicated to NFS if I understand correctly, so it should make the server more responsive ?

Lowering rsize wsize to 1 does not change anything. Everything is completely stuck on Ubuntu client until end of copy.

As everything is quite responsive on Windows, I guess this is more likely to be a mount parameter issue...

I also noticed that the copy operation, if issued on a command line, is not interruptible by Ctrl+C. If I copy the same big file to another local disk, Ctrl+C is working. Could that be related ?

Ok, problem solved by mounting with these mount options (no changes on the Raspberry side):

raspberrypi:/mnt/DataBackupNAS /media/laurent/DataBackupNAS nfs vers=4,sync 0 0

So sync has to be explicitely enabled (which is a bit surprising, I was expecting async to give more reactivity !).

Nautilus and ls commands are now refreshing almost instantly, and the cp command can be interrupted with Ctrl+C.

@Terrance: Thanks for the suggestion, that was my first thought too, but the problem was also happening using command lines (cp and ls for listing).