NFS: client needs to write twice (!) for a successful write


I was looking for a couple of days for a solution, so (I think) I have the basics sorted out - i.e. correct /etc/exports, correct mount, no firewall, matching UIDs/GUIs, correct squash-ing etc.

The (weird) problem: a server (an Intel SS4200) exports an NFS share mapped by an 11.1 client (tried both YaST-way and CLI-way on the client). I can access and read from the share. However, when trying to write to the share (a simple ‘cp’) I observe the following behavior:

  • The first time the ‘cp’ command is issued, it ends up with:
    cp: cannot create regular file `./test.txt’: Invalid argument
    The above results in a zero-size file with correct filename being created.
  • The second time (1 sec later) the ‘cp’ command is re-issued, the copy is performed fine and the contents of the file are intact.

On both client & server there are no messages in /var/log/messages when the first ‘cp’ fails.

Any ideas where/what to keep looking for?

Hi, we have the exact same problem and were wondering if you or anyone else had come up with a solution. In our case, the same problem exists on an OpenFiler we’ve built and we’re trying to access an NFS share on it from a Fedora client. We’ve posted the info on the OpenFiler forum, but haven’t heard anything back from there yet. We’ve tried almost everything and are out of ideas. What’s interesting, is that we have an NFS server built on a plan Fedora server and writing to an NFS share on that server works perfectly. We can’t discern what the difference is.

Any help is greatly appreciated!



exist any solution for this bug / problem?
I have the same problem with my workstation and I tried
the new Ubuntu Version and I have no problem with nfs.

I also had this problem on my Intel SS4200-E and just figured it out.

It’s due to ACLs being set on the filesystem which is (for whatever reason) affecting file copying under NFS.

First enable SSH on the SS4200 and log in as root.

To show your current ACLs:

getfacl /mnt/soho_storage/samba/shares/test

To clear these out:

setfacl -b /mnt/soho_storage/samba/shares/test

After doing this, I could now copy/create files without first creating the zero byte files.

This is not a complete fix however, as if you change the access lists in the web gui it could be reset. I also have not tried yet whether this persists after a reboot. It also opens the files to everyone.

It is likely possible to fix this permanently, or at least adjust the ACLs more correctly rather than just clearing them. I have not looked into this yet.

Hope this helps.