cp -p failed to preserve ownership invalid argument

[webpex]

I have two CentOS servers which mount a ReadyNAS 2120 for backup purposes. One was an existing database server, the other is new.
The existing database server can mount and copy files with the 'cp -p' command with no problem.

The new sever generates the following error:

[root@dbn10 dbn10]# cp -p /tmp/test.txt /NAS_BACKUP/dbn10/test.txt
cp: failed to preserve ownership for `/NAS_BACKUP/dbn10/test.txt': Invalid argument

This is a problem because we use a number of automated scripts to backup our database and they use the 'cp -p' command.
Altering them is unfortunately not feasible. Everything is done with root user accounts.

The ReadyNas is configured with no_root_squash and the /etc/exports looks like this (IP's are masked):

"/homes" *(insecure,insecure_locks,no_root_squash,anongid=99,anonuid=99,no_subtree_check,rw,sync)
"/run/nfs4" *(ro,sync,insecure,insecure_locks,no_root_squash,anongid=99,anonuid=99,no_subtree_check,fsid=0)
"/run/nfs4/Raid6MainVolume" *(ro,sync,insecure,insecure_locks,no_root_squash,anongid=99,anonuid=99,no_subtree_check,fsid=2901131141)
"/run/nfs4/Raid6MainVolume/mysql_backup" IP1.***.***.***(insecure,insecure_locks,no_subtree_check,rw,no_root_squash)  IP2.***.***.***(insecure,insecure_locks,no_subtree_check,rw,no_root_squash)
"/Raid6MainVolume/mysql_backup" IP1.***.***.***(insecure,insecure_locks,no_subtree_check,rw,no_root_squash)  IP2.***.***.***(insecure,insecure_locks,no_subtree_check,rw,no_root_squash)

Other info looks like this:

Working:

CentOS release 5.9 (Final)
Mount: [NAS_IP]:/Raid6MainVolume/mysql_backup on /NAS_BACKUP type nfs (rw,addr=[NAS_IP])
CP: cp (GNU coreutils) 5.97

Not Working:

CentOS release 6.4 (Final)
Mount: [NAS_IP]:/Raid6MainVolume/mysql_backup on /NAS_BACKUP type nfs (rw,vers=4,addr=[NAS_IP],clientaddr=[CLIENT_IP])
cp (GNU coreutils) 8.4

strace on the cp has this interesting section which obviously is the problem:

write(4, "this is a test file\n", 20)   = 20
read(3, "", 262144)                     = 0
utimensat(4, NULL, {{1374099629, 183519670}, {1374099608, 72130346}}, 0) = 0
fsetxattr(4, "system.posix_acl_access", "\x02\x00\x00\x00\x01\x00\x06\x00\xff\xff\xff\xff\x04\x00\x00\x00\xff\xff\xff\xff \x00\x00\x00\xff\xff\xff\xff", 28, 0) = -1 EOPNOTSUPP (Operation not supported)
fchmod(4, 0600)                         = 0
fchown(4, 0, 0)                         = -1 EINVAL (Invalid argument)
fchown(4, 4294967295, 0)                = -1 EINVAL (Invalid argument)
open("/usr/share/locale/locale.alias", O_RDONLY) = 5

It looks like setting extended attributes on the ReadyNas does not work...

Any ideas on why the older one works and new one doesn't? Or how to fix this? Been pulling my hair out over this.

Thanks

[JohnnyB11]

webpex wrote:
Any ideas on why the older one works and new one doesn't? Or how to fix this? Been pulling my hair out over this.

Maybe. But first:
1. Your server running CentOS release 5.9 mounts /NAS_BACKUP with type nfs.
2. Your server running CentOS release 6.4 mounts /NAS_BACKUP type nfs but uses the mount option vers=4.

So, what NFS version do you really want to use? The version used is important because NFSv4 needs a different fsetxattr call. The second parameter must be "system.nfs4_acl" instead of "system.posix_acl_access". The latter is used by your "cp -p" as shown in the strace output above. So what might happen is: Your server running CentOS release 6.4 respects the mount option and uses NFSv4 for the "connection". However, your server itself thinks it is NFSv3 since mount says so. Thus, the wrong fsetxattr call is used by "cp -p". Your server running CentOS release 5.9 uses NFSv3 for the "connection", too, and there the fsetxattr with parameter "system.posix_acl_access" works fine.

And, even if your server running CentOS release 5.9 used NFSv4, you would not see the error. This is because there was a bug in coreutils <6.12 such that "cp -p" silently ignored the EOPNOTSUPP error code of fsetxattr and thereby removed the ACL, see https://bugzilla.redhat.com/show_bug.cgi?id=454072

[webpex]

Excellent response! Thank you. I did end up figuring that it was a difference in NFSv3 vs NFVv4. The server with the problem was trying to mount the NAS with v4 while the server that worked was using v3. I was able to rectify the problem by specifying the NFS version I wanted to use in the mount:

mount -t nfs [ip-addr]:/Raid6MainVolume/mysql_backup /nfs_test -o vers=3

[JohnnyB11]

webpex wrote:
Excellent response! Thank you.

You are welcome!