2:41 p.m.
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
4:01 p.m.
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.
--
If I wanted a blog or social media I'd go elsewhere
6:38 p.m.
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
6:46 p.m.
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.
--
If I wanted a blog or social media I'd go elsewhere
7:06 p.m.
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
--
If I wanted a blog or social media I'd go elsewhere
9:34 p.m.
On 26Jul2015 08:06, Ed Greshko <ed.greshko(a)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(a)zip.com.au>
Music journalism: People who can't write interviewing people who can't talk
for people who can't read. - Frank Zappa
9:39 p.m.
On 07/26/15 10:34, Cameron Simpson wrote:
On 26Jul2015 08:06, Ed Greshko <ed.greshko(a)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.
--
If I wanted a blog or social media I'd go elsewhere
10:31 p.m.
On 26Jul2015 10:39, Ed Greshko <ed.greshko(a)greshko.com> wrote:
On 07/26/15 10:34, Cameron Simpson wrote:
> On 26Jul2015 08:06, Ed Greshko <ed.greshko(a)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(a)zip.com.au>
9:34 a.m.
On 07/25/2015 08:31 PM, Cameron Simpson wrote:
On 26Jul2015 10:39, Ed Greshko <ed.greshko(a)greshko.com> wrote:
> On 07/26/15 10:34, Cameron Simpson wrote:
>> On 26Jul2015 08:06, Ed Greshko <ed.greshko(a)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(a)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
9:45 a.m.
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(a)greshko.com> wrote:
>> On 07/26/15 10:34, Cameron Simpson wrote:
>>> On 26Jul2015 08:06, Ed Greshko <ed.greshko(a)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(a)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".
--
If I wanted a blog or social media I'd go elsewhere
3:42 p.m.
New subject: OT - NFS group ignored [SOLVED]
On 07/25/2015 08:31 PM, Cameron Simpson wrote:
On 26Jul2015 10:39, Ed Greshko <ed.greshko(a)greshko.com> wrote:
> On 07/26/15 10:34, Cameron Simpson wrote:
>> On 26Jul2015 08:06, Ed Greshko <ed.greshko(a)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(a)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
4:17 p.m.
New subject: OT - NFS group ignored [SOLVED]
----- Original Message -----
| On 07/25/2015 08:31 PM, Cameron Simpson wrote:
| > On 26Jul2015 10:39, Ed Greshko <ed.greshko(a)greshko.com> wrote:
| >> On 07/26/15 10:34, Cameron Simpson wrote:
| >>> On 26Jul2015 08:06, Ed Greshko <ed.greshko(a)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(a)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. ;)
--
James A. Peltier
IT Services - Research Computing Group
Simon Fraser University - Burnaby Campus
Phone : 604-365-6432
Fax : 778-782-3045
E-Mail : jpeltier(a)sfu.ca
Website : http://www.sfu.ca/itservices
Twitter : @sfu_rcg
Powering Engagement Through Technology
6:33 p.m.
New subject: OT - NFS group ignored [SOLVED]
On 26Jul2015 13:42, Emmett Culley <lst_manage(a)webengineer.com> wrote:
On 07/25/2015 08:31 PM, Cameron Simpson wrote:
> On 26Jul2015 10:39, Ed Greshko <ed.greshko(a)greshko.com> wrote:
>> On 07/26/15 10:34, Cameron Simpson wrote:
>>> On 26Jul2015 08:06, Ed Greshko <ed.greshko(a)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(a)zip.com.au>
In article <323C4DB9.6A76(a)ss1.csd.sc.edu>, lhartley(a)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(a)agames.com> in rec.moto
3190
days inactive
3191
days old
13 comments
4 participants
participants (4)
-
Cameron Simpson -
Ed Greshko -
Emmett Culley -
James A. Peltier