Change owner with NFSv4

[thies1965]

Hi,

we struggle with changing the owner of a file / folder residing on qtree with UNIX security style.

The qtree is exported with root=<IP adress of Linux client> and rw rights

The client is a Suse SLES11. We are logged-in as root on the client. The nfs export is mounted and NFSv4 is active with Kerberosv5.

Setting and changing ACLs is no problem: nfs4_setfacl works on files and on folders. Even if we create a new file, the owner is root (group also root).

But if we try to execute chown of a file, we receive an error message:

chown mthies2 root2-ls-la.txt

chown: changing ownership of `root2-ls-la.txt': Invalid argument

In theory, I thought it has to work, since root exported and root identified. But chown is not possible, only if we step back to NFSv3.

So as a consequence, is it correct that chown is not possible using NFSv4 with Kerberos?

[shaunjurr]

Hi,

I'm actually wondering how you got any operation in your (probably bash) shell completed on a file with hyphens ( - ) without getting an error.

Try escaping special characters in file names (if you really have to use them) with a backslash  or single quotes.

You should review the linux manpage (or whatever other help system your distro uses) as well as check what the filer sees as export/mount rights by using 'exportfs -c .... ' ... see the NetApp manpage for exportfs.

[thies1965]

well, the hyphen is not really a problem.

Maybe, I have to rephrase my question.

The NFSv4 down-grades the root to nobody. And there seems to be no way, to assign a user accessing a NFS mount via NFSv4 root rights on the filer. Without root rights on the filer, there is no way to change the owner of a file.

So I was wondering, whether that implication is correct.

[shaunjurr]

Hi,

The automatic downgrading, I would think, is the result of not being able to map who root is, perhaps.  Anyway, that would break just about everything.  NFSv4 is just hard to implement in mixed environments if one wants to share anything CIFS and NFS since one needs to use the AD controller for kerberos because no unix variants exist that support CIFS... but I digress...

The only other apparent possible error is a bug in the linux (l33n0x) implementation for NFSv4.  A quick Google search points to recent situations such as yours.

[thies1965]

I finally could solve the issue.

It was tricky.

The root cause was that the idmap daemon didn't run. SInce we use SLES11, even the client needs the nfsd to run. After having that nfsd up and running, also the gss and idmap processes could start. Afterwards the chown did work out even the setting of "o" right ACL to a technical user worked out. So there is no need to work with root anymore.

[mowillers]

I had the same problem on RHEL 6.3 and it was due to a bug in nfs-utils. The fix for me was to upgrade to a version of nfs-utils which contained the following fix:

* Mon Nov 05 2012 Steve Dickson <steved@redhat.com> 1.2.3-31

- Allow ID strings in idmapping to be handled correctly (bz 849945)

Also see this discussion: http://www.spinics.net/lists/linux-nfs/msg38638.html