2

I have been trying to get to the bottom of a strange errors when extracting tar archives on an NFS share.

The errors manifest themselves when extracting a tar files which include files which have been archived without write permissions set on the archived files.

Error messages intermittently are printed like:

tar: test/doc/manpages/man1/Makefile.in: Cannot close: Input/output error

To confirm this behaviour I set up two identical tar files: One with the archived files set with chmod permissions 575 (user read/execute) and one with chmod permissions set to 755 (user read/write/execute).

Both tar files were archived as follows:

tar czf test.tgz test

And extracted as follows:

tar -xvzf test.tgz

When extracting both archives on the local file system I did not get any errors. Additionally, when extracting the archive with with user write on the NFS share I do not get any errors. The errors always occurred when extracting the archive set without user write permissions on the archived files onto the NFS share.

The NFS share is configured with the following export parameters:

/media/share 10.0.0.3(rw,sync,no_subtree_check,no_root_squash)

And the client fstab entry for the NFS mount is as follows:

10.0.0.3:/media/share /media/share nfs4 rw,_netdev,auto,clientaddr=10.0.0.10 0 0

Both the client and server are running Ubuntu 14.04.1

The nfs-common version on the both the client and server is v1:1.2.8-6ubuntu1.2 and the nfs-kernel-server package on the server is also v1:1.2.8-6ubuntu1.2

Any help would be appreciated as I would like to get to the bottom of what is causing these errors.

2
  • The error message you pasted is from the tar command executed on the client. Did you look at kernel logs for NFS client? Do you have access to server-side logs? If so would you share them?
    – Marco
    Oct 4, 2017 at 19:33
  • how big is your tar final file? One of the reasons can be too big local filesystem cache, which get's flushed by close. You can force early flush by setting vm.dirty_background_bytes = 67108864 and vm.dirty_bytes = 536870912
    – kofemann
    Oct 5, 2017 at 5:41

1 Answer 1

1

After much troubleshooting it seems that, in my case, these errors were related to the clientaddr mount option in the fstab entries on some of our client machines being set to the incorrect IP address. Having gone through each host, ensuring all clientaddr values were correct and remounting the volume I was able to extract both archives, previously described, without any errors.

It should be noted that the NFS man page specifically mentions, with respect to the clientaddr mount option, that:

If the server is unable to establish callback connections to clients, performance may degrade, or accesses to files may temporarily hang.

I therefor suspect that the issues I was seeing were related to the server being unable to establish callback connections to the clients which were configured with the wrong client callback addresses.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .