Invalid argument when using cp -p to nfs mount
 

Hi,

I'm attempting to copy a file to an nfs mounted file system located on another server, I would like to copy the file so that the file attributes are preserved so I'm adding the -p to the cp command. When I do this I receive the following error messages.

saplap06:/usr/sap/EE1/home/ee1adm # ls -al sapmnt_exe.txt
-rw-r--r-- 1 ee1adm sapsys 9514 Aug 14 09:57 sapmnt_exe.txt
saplap06:/usr/sap/EE1/home/ee1adm # cp -p sapmnt_exe.txt /mnt
cp: failed to preserve ownership for `/mnt/sapmnt_exe.txt': Operation not permitted
saplap06:/usr/sap/EE1/home/ee1adm # cp -p sapmnt_exe.txt /sapmnt/EK1/global
cp: setting permissions for `/sapmnt/EK1/global/sapmnt_exe.txt': Invalid argument

The file is being copied to nfs mount points which are mounted as follows.

sapkon01:/sapmnt/EK1/global on /sapmnt/EK1/global type nfs (rw,bg,hard,intr,noacl,addr=140.16.4.75)
saturn:/tmp on /mnt type nfs (rw,addr=140.14.45.83)

This error occurs on all nfs mount configurations I have tried, even on a locally mounted nfs mount point, I can copy the file using cp without switches and then change the attributes manually but this is not a solution.

My question, is this a feature that nfs does not support, a bug or an error in how I'm mounting the file system?

The systems in use are running SLES9 sp2 and sp3.

Thanks and regards,

Stuart Symonds.

Are the uid and gid numbers for user 'ee1adm' and group 'sapsys' the same on both systems? That is, if you type this command on each system, do you get the same results? I'm not positive it's necessary, but I think it is. (And chown would still work even if the numbers are different.)

None of the above. NFS supports that feature but you can't do anything from the client side.

You typically can't chown a file on a NFS remote file-sytem, as root is mapped to "nobody", which has no superusers rights.

On the NFS server side, it is possible to allow real root access from a list of machines by using a dedicated option ("root=access list" on Solaris share_nfs), you can also, if you like living dangerously, allow root from any machine (anon=0)

Thankyou both for the help and prompt reply, the issue is now resolved.

Thanks again, Stuart

How was it resolved ?

Hi jlliagre,

Resolved by implementing an access control list as you suggested.

Now I understand the problem I've tested a solution on a SLES system with the following configured in exports.

/tmp saplap06(rw,no_root_squash,sync)

The mount the user wants configured is on a Sun Solaris system which I have no access too. Its up to the sysadmin for that system to configure the export, from your post I gather the syntax is different for Solaris systems.

Regards, Stuart

Indeed, thanks for sharing.