I have a NFS server running on CentOS7 nfs-utils-1.3.0-0.21.el7.x86_64
Basically the oddity I am finding is as follows:
server and client have same user and group with same uid's and gid's
Client can only write to an exported folder if it "other/all" permission
is set to write. I can get around this by using all_squash and setting
the anon id's but this isn't really what I want.
Am I missing a step that would allow this to work without all_squash.
This is my setup:
server0: where nfs-server is running
client: where export is mounted
Groups and uids all match on both machines
[root@server0 ~]# groups user
user : user common
[root@server0 ~]# cat /etc/passwd | grep 'common\|^user'
common:x:20000:20000:common:/home/common:/bin/bash
user:x:1000:1000::/:/sbin/nologin
[user@client ~] $ groups user
user : user lp common
[user@client ~] $ cat /etc/passwd | grep 'common\|^user'
user:x:1000:1000:user:/home/user:/bin/bash
common:x:20000:20000::/:/sbin/nologin
server0 setup:
[root@server0 ~]# ls -lr /test*
drwxrwxrwx. 2 common common 6 Jan 7 16:05 /test_squash/chmod777
drwxrwxr-x. 2 common common 6 Jan 7 16:06 /test_squash/chmod775
drwxrwxrwx. 2 common common 6 Jan 7 16:05 /test/chmod777
drwxrwxr-x. 2 common common 6 Jan 7 16:05 /test/chmod775
[root@server0 ~]# cat /etc/exports
/test 192.168.1.0/24(rw,async)
/test_squash 192.168.1.0/24(rw,async,all_squash,anonuid=20000,anongid=20000)
[root@server0 ~]# systemctl restart nfs-server
client setup:
[user@client ~] $ cat /etc/fstab | grep '^server'
server0:/test /test nfs defaults 0 0
server0:/test_squash /test_squash nfs defaults 0 0
[user@client ~] $ sudo mount /test
[user@client ~] $ sudo mount /test_squash
[user@client ~] 1 $ touch /test_squash/chmod777/file
[user@client ~] $ touch /test_squash/chmod775/file
[user@client ~] $ touch /test/chmod777/file
[user@client ~] $ touch /test/chmod775/file
touch: cannot touch ‘/test/chmod775/file’: Permission denied
[user@client ~] $ ls -lR /test*
drwxrwxr-x. 2 common common 6 Jan 7 16:05 /test/chmod775
drwxrwxrwx. 2 common common 17 Jan 7 16:27 /test/chmod777
-rw-rw-r--. 1 user user 0 Jan 7 16:27 /test/chmod777/file
drwxrwxr-x. 2 common common 17 Jan 7 16:28 /test_squash/chmod775
drwxrwxrwx. 2 common common 17 Jan 7 16:28 /test_squash/chmod777
-rw-rw-r--. 1 common common 0 Jan 7 16:28 /test_squash/chmod775/file
-rw-rw-r--. 1 common common 0 Jan 7 16:28 /test_squash/chmod777/file
So my real question is why cant user:user create a file in /test/chmod775 ?
Thanks for any help.
-Robb
On Thu, Jan 07, 2016 at 05:02:19PM -0600, Robb wrote:
> I have a NFS server running on CentOS7 nfs-utils-1.3.0-0.21.el7.x86_64
>
> Basically the oddity I am finding is as follows:
> server and client have same user and group with same uid's and gid's
>
> Client can only write to an exported folder if it "other/all" permission
> is set to write. I can get around this by using all_squash and setting
> the anon id's but this isn't really what I want.
>
> Am I missing a step that would allow this to work without all_squash.
>
> This is my setup:
> server0: where nfs-server is running
> client: where export is mounted
>
>
> Groups and uids all match on both machines
> [root@server0 ~]# groups user
> user : user common
> [root@server0 ~]# cat /etc/passwd | grep 'common\|^user'
> common:x:20000:20000:common:/home/common:/bin/bash
> user:x:1000:1000::/:/sbin/nologin
>
> [user@client ~] $ groups user
> user : user lp common
> [user@client ~] $ cat /etc/passwd | grep 'common\|^user'
> user:x:1000:1000:user:/home/user:/bin/bash
> common:x:20000:20000::/:/sbin/nologin
>
>
> server0 setup:
>
> [root@server0 ~]# ls -lr /test*
> drwxrwxrwx. 2 common common 6 Jan 7 16:05 /test_squash/chmod777
> drwxrwxr-x. 2 common common 6 Jan 7 16:06 /test_squash/chmod775
> drwxrwxrwx. 2 common common 6 Jan 7 16:05 /test/chmod777
> drwxrwxr-x. 2 common common 6 Jan 7 16:05 /test/chmod775
>
>
> [root@server0 ~]# cat /etc/exports
> /test 192.168.1.0/24(rw,async)
> /test_squash 192.168.1.0/24(rw,async,all_squash,anonuid=20000,anongid=20000)
>
> [root@server0 ~]# systemctl restart nfs-server
>
>
> client setup:
> [user@client ~] $ cat /etc/fstab | grep '^server'
> server0:/test /test nfs defaults 0 0
> server0:/test_squash /test_squash nfs defaults 0 0
>
> [user@client ~] $ sudo mount /test
> [user@client ~] $ sudo mount /test_squash
>
> [user@client ~] 1 $ touch /test_squash/chmod777/file
> [user@client ~] $ touch /test_squash/chmod775/file
> [user@client ~] $ touch /test/chmod777/file
> [user@client ~] $ touch /test/chmod775/file
> touch: cannot touch ‘/test/chmod775/file’: Permission denied
>
> [user@client ~] $ ls -lR /test*
> drwxrwxr-x. 2 common common 6 Jan 7 16:05 /test/chmod775
> drwxrwxrwx. 2 common common 17 Jan 7 16:27 /test/chmod777
> -rw-rw-r--. 1 user user 0 Jan 7 16:27 /test/chmod777/file
> drwxrwxr-x. 2 common common 17 Jan 7 16:28 /test_squash/chmod775
> drwxrwxrwx. 2 common common 17 Jan 7 16:28 /test_squash/chmod777
> -rw-rw-r--. 1 common common 0 Jan 7 16:28 /test_squash/chmod775/file
> -rw-rw-r--. 1 common common 0 Jan 7 16:28 /test_squash/chmod777/file
>
>
>
> So my real question is why cant user:user create a file in /test/chmod775 ?
Hm, and chmod775 should permit write to members of common, and user is a
member of common on both client and server (and names and uids are the
same on both).
I'm not seeing the explanation....
I think the next thing I'd do would be get a network trace:
1. run "tcpdump -s0 -wtmp.pcap"
2. try the failed "touch /test/chmod755/file"
3. kill the tcpdump
Then run "wireshark tmp.pcap" and look at the result. If this is v4
thee should be an OPEN call in there that tries to create "file", with
the server replying with an error.
It'd be especially interesting to look at the rpc header on that call,
specifically the credential, which should include a list of gid's (with
20000 being one of those gid's).
--b.
>
> Thanks for any help.
>
> -Robb
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
J. Bruce Fields <bfields@...> writes:
> > So my real question is why cant user:user create a file in
/test/chmod775 ?
>
> Hm, and chmod775 should permit write to members of common, and user is a
> member of common on both client and server (and names and uids are the
> same on both).
>
> I'm not seeing the explanation....
>
> I think the next thing I'd do would be get a network trace:
>
> 1. run "tcpdump -s0 -wtmp.pcap"
> 2. try the failed "touch /test/chmod755/file"
> 3. kill the tcpdump
>
> Then run "wireshark tmp.pcap" and look at the result. If this is v4
> thee should be an OPEN call in there that tries to create "file", with
> the server replying with an error.
>
> It'd be especially interesting to look at the rpc header on that call,
> specifically the credential, which should include a list of gid's (with
> 20000 being one of those gid's).
>
I did this and indeed 20000 was not in the list of "Auxiliary GIDs" of the
rpc header credentials as it should of been. A reboot fixed this, so now it
works.
I had restarted the terminal but it looks since I had other sessions logged
in that wasn't enough to get the new gid to propogate, I should know better.
Running
# sudo newgrp common
Probably would of fixed it for me, as it adds you to the group without
requiring logging out, I'll never trust the "groups" command again :)
Thank you helping me find the issue.
-Robb
On Fri, Jan 08, 2016 at 10:52:12PM +0000, Robb Barrows wrote:
> J. Bruce Fields <bfields@...> writes:
>
> > > So my real question is why cant user:user create a file in
> /test/chmod775 ?
> >
> > Hm, and chmod775 should permit write to members of common, and user is a
> > member of common on both client and server (and names and uids are the
> > same on both).
> >
> > I'm not seeing the explanation....
> >
> > I think the next thing I'd do would be get a network trace:
> >
> > 1. run "tcpdump -s0 -wtmp.pcap"
> > 2. try the failed "touch /test/chmod755/file"
> > 3. kill the tcpdump
> >
> > Then run "wireshark tmp.pcap" and look at the result. If this is v4
> > thee should be an OPEN call in there that tries to create "file", with
> > the server replying with an error.
> >
> > It'd be especially interesting to look at the rpc header on that call,
> > specifically the credential, which should include a list of gid's (with
> > 20000 being one of those gid's).
> >
>
> I did this and indeed 20000 was not in the list of "Auxiliary GIDs" of the
> rpc header credentials as it should of been. A reboot fixed this, so now it
> works.
>
> I had restarted the terminal but it looks since I had other sessions logged
> in that wasn't enough to get the new gid to propogate, I should know better.
>
> Running
> # sudo newgrp common
> Probably would of fixed it for me, as it adds you to the group without
> requiring logging out, I'll never trust the "groups" command again :)
>
> Thank you helping me find the issue.
Ah, I hadn't thought of that, makes sense, thanks for reporting the
solution.
--b.