- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: Strange permission problem on NFS
Operating System - HP-UX
1748234
Members
3198
Online
108759
Solutions
Forums
Categories
Company
Local Language
юдл
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
юдл
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Go to solution
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-15-2009 05:38 AM
тАО04-15-2009 05:38 AM
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 :)
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 :)
Solved! Go to Solution.
3 REPLIES 3
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-15-2009 05:50 AM
тАО04-15-2009 05:50 AM
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 ?
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 ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-15-2009 07:05 PM
тАО04-15-2009 07:05 PM
Solution
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
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
I work for HPE
[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]
[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-16-2009 12:16 AM
тАО04-16-2009 12:16 AM
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!
$ 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...
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP