Nfs file transfers fail, “cp: cannot stat ‘dir_name’: No such file or directory” but sshfs works fine

cpnfs

We have a strange issue on our file server (Debian Wheezy 32-bit), where some files within folders contained in an nfs share fail during transfer using the cp command. Howerver, if we mount the same folder via sshfs and use that to transfer files, there is no issue. We have a few things that require nfs, so sshfs is not a solution but a work around.

When trying to cp -r a folder from the mount on a client to a local folder on the client (also Debian Wheezy) one or more of the folders contained within the share will fail with the following error:

cp: cannot stat `My_Shared_Folder/dir': No such file or directory

Only some of the files contained in dir fail, others do get transferred. Oddly enough, it's the same folders each time that fail. But if I mount the same My_Shared_Folder and copy the same dir via sshfs, everything works perfect.

I checked the permissions, which appear fine. Sometimes, but not always, the permission string changes on failed directories after a file copy is attempted from the nfs mount:

ls -l My_Shared_Folder:
d????????? ? ?      ?             ?            ? dir
drwxrwxr-x 2 nobody nogroup    4096 Apr  1 15:14 dir2

In that example, when using cp -r to copy "My_Shared_Folder" locally, dir2 would have made the transfer, but not dir.

Before the file transfer is attempted, the folder permissions look fine (to me):

ls -l My_Shared_Folder:
drwxrwxr-x 3 nobody nogroup     138 Mar 20 11:51 dir
drwxrwxr-x 2 nobody nogroup    4096 Apr  1 15:14 dir2

The nfs share is shared on the server via the following line in /etc/exports:

/exports/My_Shared_Folder   10.10.10.0/21(ro,async,no_subtree_check,all_squash,anonuid=65534,anongid=65534)

The client access the share via the following fstab entry:

10.10.10.95:/exports/My_Shared_Folder   /mnt/My_Shared_Folder       nfs noatime,user,ro     0   0

Things I have tried so far:

  • I checked the permissions
  • I tried setting NEED_IDMAPD=yes to /etc/default/nfs-common
  • I verified that /etc/idmapd.conf on the server and the client both show the right domain
  • I tried restarting nfs, then the entire server out of desperation

Since sshfs works perfectly fine, I'm at the point now where I personally believe that this is an NFS issue, but perhaps I'm wrong.

Best Answer

It looks like this issue may have been caused by a combination of nfs, xfs, and inode64. I've moved the data to an ext3 volume and exported from that, and it appears to have solved it.