General
cancel
Showing results for 
Search instead for 
Did you mean: 

Strange permission problem on NFS

SOLVED
Go to solution
Rikki hinn Ogurlegi
Frequent Advisor

Strange permission problem on NFS

I've been trying to figure out a strange permission problem on a NFS mounted disk.

The NFS server and NFS client are HP-UX 11.23 (December 2008 Quality patch) on HP Integrity Virtual machines.

The NFS server:

kinnauga# hostname
kinnauga
kinnauga# model
ia64 hp server Integrity Virtual Machine
kinnauga# uname -a
HP-UX kinnauga B.11.23 U ia64 3622396596 unlimited-user license


The NFS client:

glokollur# hostname
glokollur
glokollur# model
ia64 hp server Integrity Virtual Machine
glokollur# uname -a
HP-UX glokollur B.11.23 U ia64 0108740552 unlimited-user license


The problem is that NFS is not listening to groups any more. I have a disk NFS mounted from the server on /kreb

glokollur# mount | grep kreb
/kreb on sgbotn.orkugardur.is:/export/botn rsize=32768,wsize=32768,NFSv3,dev=28 on Wed Apr 15 13:20:13 2009

glokollur# ls -ld /kreb/oliuverk
drwxrwx--- 7 bin oliuverk 8192 apr 15 11:21 /kreb/oliuverk

glokollur# ls -lnd /kreb/oliuverk
drwxrwx--- 7 2 108 8192 apr 15 11:21 /kreb/oliuverk

Here the group oliuverk (gid 108) should have full access to the folder. A typical user:

-bash-3.2$ hostname
glokollur
-bash-3.2$ id
uid=246(hs) gid=5424(oms) groups=1009(tolvunefnd),1018(heimildasafn),159(OBD949000),153(OBD943000),34(bhm),158(obd),62(gis),154(OBD944000),20(users),151(OBD941000),22(fordi),959(intranet),157(OBD947000),106(olia),952(gull),152(OBD942000),108(oliuverk),300(ffr),2088(oms-bin)

Here user hs is in the group oliuverk (gid 108) but this happens:

-bash-3.2$ cd /kreb/oliuverk
-bash: cd: /kreb/oliuverk: Permission denied

If I create a local folder as root on the NFS client I get different results:

glokollur# mkdir /tmp/oliuverk
glokollur# chown bin:oliuverk /tmp/oliuverk
glokollur# chmod 770 /tmp/oliuverk
glokollur# ls -ld /tmp/oliuverk
drwxrwx--- 2 bin oliuverk 96 apr 15 13:23 /tmp/oliuverk
glokollur# ls -lnd /tmp/oliuverk
drwxrwx--- 2 2 108 96 apr 15 13:23 /tmp/oliuverk


Same setup as the NFS folder, except it's local to the client in it's /tmp folder. Here is what happens:

-bash-3.2$ cd /tmp/oliuverk
-bash-3.2$ pwd
/tmp/oliuverk


I cant see any problems with the groups:

-bash-3.2$ grep 108 /etc/group
-bash-3.2$ grget | grep 108
oliuverk:*:108:ke,anb,gme,gsj,sth,sv,sigrima,hs,thbr,thes,thsa,asa,itkuld,br,kg

(this is a LDAP setup)

I can even demonstrate a Cool aspect of the problem:

Again, on the client, as root:

glokollur# chmod 2777 /kreb/oliuverk
glokollur# ls -ld /kreb/oliuverk
drwxrwsrwx 7 bin oliuverk 8192 apr 15 11:21 /kreb/oliuverk

Now the folder is open, with the setgid bit on the group. Now this happens for the user:

-bash-3.2$ cd /kreb/oliuverk
-bash-3.2$ touch testfile
-bash-3.2$ ls -l testfile
-rw-r----- 1 hs oliuverk 0 apr 15 13:27 testfile
-bash-3.2$ ls -ln testfile
-rw-r----- 1 246 108 0 apr 15 13:27 testfile


So obviously the group is working since the setgid group on the folder works and the new file gets created in the oliuverk(108) group.

I tested this with pwgrd killed with no change.

The export line on the server is:

kinnauga# grep ^XFS /etc/cmcluster/sgbotn/hanfs.sh
XFS[0]="-i -o access=vindauga:kinnauga:strokkur:tuska:sgbotn:@10.1.0.0/16:@10.10.32.0/21:@10.11.32.0/21:@10.12.32.0/21:@10.10.24.0/21:@10.11.24.0/21:@10.12.24.0/21,root=vindauga:kinnauga:strokkur:tuska:sgbotn:glokollur,async /export/botn"


I've tried everything I can think of, but this really has me baffled :)
3 REPLIES
Rikki hinn Ogurlegi
Frequent Advisor

Re: Strange permission problem on NFS

I just found a new piece of info on this issue:

glokollur# grget -n oliuverk >> /etc/group
glokollur# tail -1 /etc/group
oliuverk:*:108:ke,anb,gme,gsj,sth,sv,sigrima,hs,thbr,thes,thsa,asa,itkuld,br,kg
-bash-3.2$ ls -ld /kreb/oliuverk
drwxrwx--- 7 bin oliuverk 8192 apr 15 13:27 /kreb/oliuverk
-bash-3.2$ cd /kreb/oliuverk
-bash-3.2$ pwd
/kreb/oliuverk


So as long as the group is in the clients local /etc/group file, it works. I took the group directly from LDAP and put it as is into /etc/group and then things work.

glokollur# swlist | grep -i ldap
J4269AA B.04.17 LDAP-UX Integration


Possibly a LDAP-UX bug ?
Dave Olker
HPE Pro
Solution

Re: Strange permission problem on NFS

Hi Rikki,

Here's the first thing I noticed:

1 - 1009(tolvunefnd)
2 - 1018(heimildasafn)
3 - 159(OBD949000)
4 - 153(OBD943000)
5 - 34(bhm)
6 - 158(obd)
7 - 62(gis)
8 - 154(OBD944000)
9 - 20(users)
10 - 151(OBD941000)
11 - 22(fordi)
12 - 959(intranet)
13 - 157(OBD947000)
14 - 106(olia)
15 - 952(gull)
16 - 152(OBD942000)
17 - 108(oliuverk)
19 - 300(ffr)
20 - 2088(oms-bin)

The group you're using for permissions is 108, which happens to be the 17th group in the list. NFS/RPC has a limitation of only allowing 16 groups to be sent in an RPC header, so only the first 16 groups will be evaluated for permissions. You can bypass this limitation by using Kerberos for authentication as opposed to the standard UNIX authentication, but that's only available at 11i v3.

The first thing I'd suggest is reordering your group list to ensure 108 comes up in the first 16 groups for this user. See if that makes a difference.

Regards,

Dave
Armin Kunaschik
Esteemed Contributor

Re: Strange permission problem on NFS

There is another hard limit of groups a user can be a member of:
$ grep NGROUPS_MAX /usr/include/limits.h
# define NGROUPS_MAX 20 /* Maximum number of simultaneous

There are other UNIX flavours with different limits.
So in general it's not a great idea to have users in more than 16 groups (1 primary group and 15 secondary) simultaneously!

My 2 cents,
Armin

PS: Please assign points if you find answers useful!
And now for something completely different...