/data 10.1.2.3(rw,sync,no_subtree_check,no_root_squash) I have the above in /etc/exports, root on the NFS client can't run chown, it gets EINVAL. Both client and server are running Debian/Wheezy but the server has kernel 3.11 from Debian/Unstable (for BTRFS). I don't think it's a BTRFS issue as I have another BTRFS NFS server that works well. Any suggestions as to what I should investigate? Please include the "obvious" things as I probably missed something that's supposed to be obvious. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
Could it be that chown is trying to do the user name to user number conversion on the local system but the target user does not exist there? Cheers ... Duncan. On Thu, Feb 13, 2014 at 07:29:06PM +1100, Russell Coker wrote:
/data 10.1.2.3(rw,sync,no_subtree_check,no_root_squash)
I have the above in /etc/exports, root on the NFS client can't run chown, it gets EINVAL. Both client and server are running Debian/Wheezy but the server has kernel 3.11 from Debian/Unstable (for BTRFS).
I don't think it's a BTRFS issue as I have another BTRFS NFS server that works well.
Any suggestions as to what I should investigate? Please include the "obvious" things as I probably missed something that's supposed to be obvious.
-- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
-- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html
On Thu, 13 Feb 2014, Duncan Roe <duncan_roe@acslink.net.au> wrote:
Could it be that chown is trying to do the user name to user number conversion on the local system but the target user does not exist there?
No, it's getting EACCESS from the system call. Here's some strace output: fchownat(AT_FDCWD, "test", 111, -1, 0) = -1 EINVAL (Invalid argument) -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On Fri, Feb 14, 2014 at 12:55:41PM +1100, Russell Coker wrote:
On Thu, 13 Feb 2014, Duncan Roe <duncan_roe@acslink.net.au> wrote:
Could it be that chown is trying to do the user name to user number conversion on the local system but the target user does not exist there?
No, it's getting EACCESS from the system call. Here's some strace output:
fchownat(AT_FDCWD, "test", 111, -1, 0) = -1 EINVAL (Invalid argument)
That's not EACCESS, it's EINVAL
Try mounting with first nfs v3 and then nfs v4, see if it makes any difference? Worth noting that NFS v4's uid mapping feature had a very, very long-standing bug on Linux that caused pretty odd behaviour in regard to permissions, but after years it was marked as fixed upstream last month. But it'll still be busted in wheezy and 3.11. T On 13 February 2014 19:29, Russell Coker <russell@coker.com.au> wrote:
/data 10.1.2.3(rw,sync,no_subtree_check,no_root_squash)
I have the above in /etc/exports, root on the NFS client can't run chown, it gets EINVAL. Both client and server are running Debian/Wheezy but the server has kernel 3.11 from Debian/Unstable (for BTRFS).
I don't think it's a BTRFS issue as I have another BTRFS NFS server that works well.
Any suggestions as to what I should investigate? Please include the "obvious" things as I probably missed something that's supposed to be obvious.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
_______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
-- Turning and turning in the widening gyre The falcon cannot hear the falconer Things fall apart; the center cannot hold Mere anarchy is loosed upon the world
On Fri, 14 Feb 2014, Toby Corkindale <toby@dryft.net> wrote:
Try mounting with first nfs v3 and then nfs v4, see if it makes any difference?
Worth noting that NFS v4's uid mapping feature had a very, very long-standing bug on Linux that caused pretty odd behaviour in regard to permissions, but after years it was marked as fixed upstream last month. But it'll still be busted in wheezy and 3.11.
Thanks for the suggestion. I have upgraded the NFS clients in question to the 3.12 kernel from Debian/Unstable and that problem is fixed now. I'm using SATA-USB devices formatted as BTRFS for most of my backups which has compelled me to upgrade most systems to newer kernels than I usually run. So running a kernel from Unstable for NFS reasons isn't a big deal. The client system that was already working was running a 3.12 kernel, so my problem report was obviously lacking in that regard. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
participants (4)
-
Duncan Roe -
Russell Coker -
Toby Corkindale -
trentbuck＠gmail.com