I just noticed that when accessing an NFS mount, the group is ignored.
For example, on the server that shares the files via NFS that lists from the NFS client as:
$ ls -l/nfs/web -rw-rw-r-- 1 root web_prog 491 Oct 16 2012 parse.php
$ mount web:/ on /lvh1/web type nfs4 (rw,noatime,vers=4.0,rsize=524288,wsize=524288,namlen=255,soft,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.6.12,local_lock=none,addr=192.168.6.232)
A user on the client machine that is a member of group web_prog cannot write the file (parse.php). If the user is changed from root to the client user's UID via chown on the server, the user on the client machine can then write the file.
The server is on CentOS 7 and the client is on Fedora 21. If I do the same test from a CentOS 7 or CentOS 6 machine client, it works as expected. That is, the group permissions are honoured by the NFS client on those non-Fedora machines.
So, I figure there is something wrong with my Fedora NFS configuration. Nothing shows up that is related to this issue when searching the Internet.
What I have tried:
Insure that Domain in /etc/idmapd.conf is the same on both client and server. Though the fact that the user ID is honoured would indicate that is correct.
Insured that the numerical user ID and group ID match on both client and server, even though until now I always assumed that idmapd did not require the numerical IDs to match with NFS4
Any help would be appreciated.
Emmett
On 07/26/15 03:41, Emmett Culley wrote:
I just noticed that when accessing an NFS mount, the group is ignored.
For example, on the server that shares the files via NFS that lists from the NFS client as:
$ ls -l/nfs/web -rw-rw-r-- 1 root web_prog 491 Oct 16 2012 parse.php
$ mount web:/ on /lvh1/web type nfs4 (rw,noatime,vers=4.0,rsize=524288,wsize=524288,namlen=255,soft,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.6.12,local_lock=none,addr=192.168.6.232)
A user on the client machine that is a member of group web_prog cannot write the file (parse.php). If the user is changed from root to the client user's UID via chown on the server, the user on the client machine can then write the file.
The server is on CentOS 7 and the client is on Fedora 21. If I do the same test from a CentOS 7 or CentOS 6 machine client, it works as expected. That is, the group permissions are honoured by the NFS client on those non-Fedora machines.
So, I figure there is something wrong with my Fedora NFS configuration. Nothing shows up that is related to this issue when searching the Internet.
What I have tried:
Insure that Domain in /etc/idmapd.conf is the same on both client and server. Though the fact that the user ID is honoured would indicate that is correct.
Insured that the numerical user ID and group ID match on both client and server, even though until now I always assumed that idmapd did not require the numerical IDs to match with NFS4
Any help would be appreciated.
What is the output of "ls -l /nfs/we" after you have performed the mount?
Remember, the UID/GID are held in the file system itself. Before you mount, it will be the UID/GID of the mount point and after you mount it will be the UID/GID held by the newly mounted file system.
On 07/25/2015 02:01 PM, Ed Greshko wrote:
On 07/26/15 03:41, Emmett Culley wrote:
I just noticed that when accessing an NFS mount, the group is ignored.
For example, on the server that shares the files via NFS that lists from the NFS client as:
$ ls -l/nfs/web -rw-rw-r-- 1 root web_prog 491 Oct 16 2012 parse.php
$ mount web:/ on /lvh1/web type nfs4 (rw,noatime,vers=4.0,rsize=524288,wsize=524288,namlen=255,soft,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.6.12,local_lock=none,addr=192.168.6.232)
A user on the client machine that is a member of group web_prog cannot write the file (parse.php). If the user is changed from root to the client user's UID via chown on the server, the user on the client machine can then write the file.
The server is on CentOS 7 and the client is on Fedora 21. If I do the same test from a CentOS 7 or CentOS 6 machine client, it works as expected. That is, the group permissions are honoured by the NFS client on those non-Fedora machines.
So, I figure there is something wrong with my Fedora NFS configuration. Nothing shows up that is related to this issue when searching the Internet.
What I have tried:
Insure that Domain in /etc/idmapd.conf is the same on both client and server. Though the fact that the user ID is honoured would indicate that is correct.
Insured that the numerical user ID and group ID match on both client and server, even though until now I always assumed that idmapd did not require the numerical IDs to match with NFS4
Any help would be appreciated.
What is the output of "ls -l /nfs/we" after you have performed the mount?
Remember, the UID/GID are held in the file system itself. Before you mount, it will be the UID/GID of the mount point and after you mount it will be the UID/GID held by the newly mounted file system.
The results of ls -l on a file in the NFS share is provided above (from the client machine).
The results of ls -ld (from the client machine) is:
drwxrwsr-x 12 root web_prog 4096 Jul 25 13:28 /nsf/web
My fedora user is definitely a member of the web_prog group and both the client and the server have the same numeric GID for that group.
I don't know if this is something new as I recently moved some files to a new server (CentOS 6 to CentOS 7), and previous to the move my Fedora user owned those files on the old server. And I only just now discovered this issue.
I also reinstalled Fedora 21 from scratch after attempting to try Fedora 22, and finding Fedora 22 not ready for prime time. Which further makes me suspect a configuration issue.
BTW, am I wrong that idmapd should not require synchronized UIDs and GIDs between client and server, at least for NFS4?
Emmett
On 07/26/15 07:38, Emmett Culley wrote:
On 07/25/2015 02:01 PM, Ed Greshko wrote:
On 07/26/15 03:41, Emmett Culley wrote:
I just noticed that when accessing an NFS mount, the group is ignored.
For example, on the server that shares the files via NFS that lists from the NFS client as:
$ ls -l/nfs/web -rw-rw-r-- 1 root web_prog 491 Oct 16 2012 parse.php
$ mount web:/ on /lvh1/web type nfs4 (rw,noatime,vers=4.0,rsize=524288,wsize=524288,namlen=255,soft,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.6.12,local_lock=none,addr=192.168.6.232)
A user on the client machine that is a member of group web_prog cannot write the file (parse.php). If the user is changed from root to the client user's UID via chown on the server, the user on the client machine can then write the file.
The server is on CentOS 7 and the client is on Fedora 21. If I do the same test from a CentOS 7 or CentOS 6 machine client, it works as expected. That is, the group permissions are honoured by the NFS client on those non-Fedora machines.
So, I figure there is something wrong with my Fedora NFS configuration. Nothing shows up that is related to this issue when searching the Internet.
What I have tried:
Insure that Domain in /etc/idmapd.conf is the same on both client and server. Though the fact that the user ID is honoured would indicate that is correct.
Insured that the numerical user ID and group ID match on both client and server, even though until now I always assumed that idmapd did not require the numerical IDs to match with NFS4
Any help would be appreciated.
What is the output of "ls -l /nfs/we" after you have performed the mount?
Remember, the UID/GID are held in the file system itself. Before you mount, it will be the UID/GID of the mount point and after you mount it will be the UID/GID held by the newly mounted file system.
The results of ls -l on a file in the NFS share is provided above (from the client machine).
The results of ls -ld (from the client machine) is:
drwxrwsr-x 12 root web_prog 4096 Jul 25 13:28 /nsf/web
Does it help if you remove the sticky bit on the mounted directory?
My fedora user is definitely a member of the web_prog group and both the client and the server have the same numeric GID for that group.
I don't know if this is something new as I recently moved some files to a new server (CentOS 6 to CentOS 7), and previous to the move my Fedora user owned those files on the old server. And I only just now discovered this issue.
I also reinstalled Fedora 21 from scratch after attempting to try Fedora 22, and finding Fedora 22 not ready for prime time. Which further makes me suspect a configuration issue.
BTW, am I wrong that idmapd should not require synchronized UIDs and GIDs between client and server, at least for NFS4?
The only thing I've needed to change in the default idmapd.conf is the Domain setting.
On 07/26/15 07:46, Ed Greshko wrote:
Does it help if you remove the sticky bit on the mounted directory?
Sorry, I meant the setgid bit.
But, FWIW, I'm trying to replicate a failure here and can't.
ds:/volume1/syntegra on /syntegra type nfs4 (rw,relatime,vers=4.0,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0, timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.18,local_lock=none,addr=192.168.1.152)
[egreshko@meimei /]$ ll -d syntegra/ drwxrwsr-x. 5 egreshko egreshko 4096 Jul 26 07:58 syntegra/
[egreshko@meimei /]$ grep ^egreshko /etc/group egreshko:x:65539:maria
Login as "maria"
[maria@meimei syntegra]$ cd /syntegra/ [maria@meimei syntegra]$ ll total 12 drwxr-xr-x. 3 egreshko egreshko 4096 May 28 11:08 backups drwxrwxrwx. 3 root root 4096 Jul 6 11:40 @eaDir drwxrwxr-x. 5 egreshko egreshko 4096 Apr 9 11:36 linux-releases [maria@meimei syntegra]$ touch x [maria@meimei syntegra]$ ll total 12 drwxr-xr-x. 3 egreshko egreshko 4096 May 28 11:08 backups drwxrwxrwx. 3 root root 4096 Jul 6 11:40 @eaDir drwxrwxr-x. 5 egreshko egreshko 4096 Apr 9 11:36 linux-releases -rw-rw-r--. 1 nobody egreshko 0 Jul 26 08:05 x
On 26Jul2015 08:06, Ed Greshko ed.greshko@greshko.com wrote:
But, FWIW, I'm trying to replicate a failure here and can't.
My standard question in this situation is: how many groups is the user in on the client machine?
Cheers, Cameron Simpson cs@zip.com.au
Music journalism: People who can't write interviewing people who can't talk for people who can't read. - Frank Zappa
On 07/26/15 10:34, Cameron Simpson wrote:
On 26Jul2015 08:06, Ed Greshko ed.greshko@greshko.com wrote:
But, FWIW, I'm trying to replicate a failure here and can't.
My standard question in this situation is: how many groups is the user in on the client machine?
Well, in my non-failing case, just 2.
Not heard of a limitation in that area.
On 26Jul2015 10:39, Ed Greshko ed.greshko@greshko.com wrote:
On 07/26/15 10:34, Cameron Simpson wrote:
On 26Jul2015 08:06, Ed Greshko ed.greshko@greshko.com wrote:
But, FWIW, I'm trying to replicate a failure here and can't.
My standard question in this situation is: how many groups is the user in on the client machine?
Well, in my non-failing case, just 2.
Not heard of a limitation in that area.
Historically there was a 16 group protocol limit on what the client passed to the NFS server, so unless the file's group was in your first 15 secondary groups it would not be consulted for file access.
Let's see what the OP has to deal with.
Cheers, Cameron Simpson cs@zip.com.au
On 07/25/2015 08:31 PM, Cameron Simpson wrote:
On 26Jul2015 10:39, Ed Greshko ed.greshko@greshko.com wrote:
On 07/26/15 10:34, Cameron Simpson wrote:
On 26Jul2015 08:06, Ed Greshko ed.greshko@greshko.com wrote:
But, FWIW, I'm trying to replicate a failure here and can't.
My standard question in this situation is: how many groups is the user in on the client machine?
Well, in my non-failing case, just 2.
Not heard of a limitation in that area.
Historically there was a 16 group protocol limit on what the client passed to the NFS server, so unless the file's group was in your first 15 secondary groups it would not be consulted for file access.
Let's see what the OP has to deal with.
Cheers, Cameron Simpson cs@zip.com.au
On the Fedora client my user is a member of ten groups, including my own. On the server my user is a member of seven groups, including my own and the web_prog group in question here.
Where can I look to find if there are "still" limitations on the number of groups passed to the server?
Anybody have a response to my question about idmapd requiring UID and/or GID numerical synchronization between client and server?
Emmett
On 07/26/15 22:34, Emmett Culley wrote:
On 07/25/2015 08:31 PM, Cameron Simpson wrote:
On 26Jul2015 10:39, Ed Greshko ed.greshko@greshko.com wrote:
On 07/26/15 10:34, Cameron Simpson wrote:
On 26Jul2015 08:06, Ed Greshko ed.greshko@greshko.com wrote:
But, FWIW, I'm trying to replicate a failure here and can't.
My standard question in this situation is: how many groups is the user in on the client machine?
Well, in my non-failing case, just 2.
Not heard of a limitation in that area.
Historically there was a 16 group protocol limit on what the client passed to the NFS server, so unless the file's group was in your first 15 secondary groups it would not be consulted for file access.
Let's see what the OP has to deal with.
Cheers, Cameron Simpson cs@zip.com.au
On the Fedora client my user is a member of ten groups, including my own. On the server my user is a member of seven groups, including my own and the web_prog group in question here.
Where can I look to find if there are "still" limitations on the number of groups passed to the server?
Google returned some information. But, being it was Sunday and I was busy I didn't spend time to digest.
Anybody have a response to my question about idmapd requiring UID and/or GID numerical synchronization between client and server?
The UIDs and GIDs on my NFS server are the same as on my clients. I don't do any mapping or make any changes to my idmapd.conf other than for the Domain.
In the examples of my tests I used my wife's account. She hasn't been a user of NFS so her UID/GID aren't the same on the server even though she has an account (some admin neglect). You can see that the UID didn't match as it became set to "nobody". Since the SetGID bit was set on the directory and the GID of the mount point is egreshko the file touched became GID of egreshko. Without the SetGID bit set it became "nobody".
On 07/25/2015 08:31 PM, Cameron Simpson wrote:
On 26Jul2015 10:39, Ed Greshko ed.greshko@greshko.com wrote:
On 07/26/15 10:34, Cameron Simpson wrote:
On 26Jul2015 08:06, Ed Greshko ed.greshko@greshko.com wrote:
But, FWIW, I'm trying to replicate a failure here and can't.
My standard question in this situation is: how many groups is the user in on the client machine?
Well, in my non-failing case, just 2.
Not heard of a limitation in that area.
Historically there was a 16 group protocol limit on what the client passed to the NFS server, so unless the file's group was in your first 15 secondary groups it would not be consulted for file access.
Let's see what the OP has to deal with.
Cheers, Cameron Simpson cs@zip.com.au
Turns out this is the clue I needed. Using the search "NFS4 group ID limitations", I found this article:
http://www.xkyle.com/solving-the-nfs-16-group-limit-problem/
Running rpc.mountd --manage-gids on the server seems to have fixed my problem. I don't know if that command is persistent, but I will soon :-)
Thanks for all your suggestions.
Emmett
----- Original Message ----- | On 07/25/2015 08:31 PM, Cameron Simpson wrote: | > On 26Jul2015 10:39, Ed Greshko ed.greshko@greshko.com wrote: | >> On 07/26/15 10:34, Cameron Simpson wrote: | >>> On 26Jul2015 08:06, Ed Greshko ed.greshko@greshko.com wrote: | >>>> But, FWIW, I'm trying to replicate a failure here and can't. | >>> | >>> My standard question in this situation is: how many groups is the user in | >>> on the client machine? | >>> | >> Well, in my non-failing case, just 2. | >> | >> Not heard of a limitation in that area. | > | > Historically there was a 16 group protocol limit on what the client passed | > to the NFS server, so unless the file's group was in your first 15 | > secondary groups it would not be consulted for file access. | > | > Let's see what the OP has to deal with. | > | > Cheers, | > Cameron Simpson cs@zip.com.au | | Turns out this is the clue I needed. Using the search "NFS4 group ID | limitations", I found this article: | | http://www.xkyle.com/solving-the-nfs-16-group-limit-problem/ | | Running rpc.mountd --manage-gids on the server seems to have fixed my | problem. I don't know if that command is persistent, but I will soon :-) | | Thanks for all your suggestions. | | Emmett
Have a look at /etc/sysconfig/nfs for adding persistence to your options. ;)
On 26Jul2015 13:42, Emmett Culley lst_manage@webengineer.com wrote:
On 07/25/2015 08:31 PM, Cameron Simpson wrote:
On 26Jul2015 10:39, Ed Greshko ed.greshko@greshko.com wrote:
On 07/26/15 10:34, Cameron Simpson wrote:
On 26Jul2015 08:06, Ed Greshko ed.greshko@greshko.com wrote:
But, FWIW, I'm trying to replicate a failure here and can't.
My standard question in this situation is: how many groups is the user in on the client machine? [...]
Historically there was a 16 group protocol limit on what the client passed to the NFS server, so unless the file's group was in your first 15 secondary groups it would not be consulted for file access. [...]
Turns out this is the clue I needed. Using the search "NFS4 group ID limitations", I found this article: http://www.xkyle.com/solving-the-nfs-16-group-limit-problem/ Running rpc.mountd --manage-gids on the server seems to have fixed my problem. I don't know if that command is persistent, but I will soon :-)
Note that this means that you are now using you're server's groups file as the basis for group membership and ignoring the client. Arguably this is both more secure and much easier to administer, but it _is_ different from the default arrangement, so don't forget it.
In a former life I wrote a user/group database (and tools), and drove both the UNIX and Windows group memberships from it. (And mailing aliases - very handy when your org has lots of projects and structural stuff; you could email "projectname" to contact all people working on that project, "projectname-leader" for the team leader and so forth - arbitrarily complex).
One side effect of this was that users ended up in many grous, allowing easy and automatic fine tuned control of fine access, but also exposing us to the 16 group limit quite often.
Therefore I have a prioritising system, which chose group membership selection - you could mark a user as needing some specific groups in an ad hoc basis, mark a group as being "useful", and otherwise the code sorted groups on probably usefulness - essentially fewest numbers of name components, and those groups were attached to files/dirs most generally.
This servered us well.
Cheers, Cameron Simpson cs@zip.com.au
In article 323C4DB9.6A76@ss1.csd.sc.edu, lhartley@ss1.csd.sc.edu wrote: | It still is true that the best touring bike is the one that you are | riding right now. Anything can be used for touring. As long as you | can travel, you are touring. I beleive such true and profound statements are NOT allowed to be posted in this newsgroup, and are also against the charter. You've been warned. - Randy Davis DoD #0013 randy@agames.com in rec.moto
-
Cameron Simpson -
Ed Greshko -
Emmett Culley -
James A. Peltier