https://bugzilla.novell.com/show_bug.cgi?id=777535 https://bugzilla.novell.com/show_bug.cgi?id=777535#c1 --- Comment #1 from lynn wilson 2012-08-27 19:29:49 UTC --- Created an attachment (id=503611) --> (http://bugzilla.novell.com/attachment.cgi?id=503611) Wireshark of the failed autofs Wireshark of the failed autofs. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=777535 https://bugzilla.novell.com/show_bug.cgi?id=777535#c2 --- Comment #2 from lynn wilson 2012-08-28 07:15:45 UTC --- Hi Correction: 12.1 does NOT work with the same config. Sorry. It seems that it is the wildcard that does not work with NFS4. What works with NFS3, does not translate to NFS4. If I mount the whole directory: /etc/auto.misc staff -rw,sec=krb5,vers=3 server:/home2/staff It works. maybe that's the best I can get. So I don't think this is a openSUSE bug. It is a feature that NFS4 does not work with wildcards in the same way that NFS3 does if the directory to mount is anything less than 0755. Thanks -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=777535 https://bugzilla.novell.com/show_bug.cgi?id=777535#c Leonardo Chiquitto changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P3 - Medium Status|NEW |ASSIGNED -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=777535 https://bugzilla.novell.com/show_bug.cgi?id=777535#c5 --- Comment #5 from lynn wilson 2012-08-28 12:55:29 UTC --- (In reply to comment #4)

This seems wrong:

# etc/exports /home2/staff *(rw,sec=krb5)

No. It's not wrong

To use NFSv4 you need at least to set the fsid (add fsid=0 to the export options).

exporting from fsid=0 is no longer needed nor recommended for Linux. Please see the nfs wiki: http://wiki.linux-nfs.org/wiki/index.php/Nfsv4_configuration (last paragraph) Please note that this syntax (without the fsid pseudoroot) works for other automounted shares which are 0755

If it still fails, please set DEFAULT_LOGGING="debug" in /etc/sysconfig/autofs, restart AutoFS and reproduce the problem. Then attach the output generated in /var/log/messages here.

In any case, I doubt it's AutoFS specific. Please also try to mount the volume manually and see if it works.

Mounting the share manually works fine: mount -t nfs server:/home2/staff /mount-point -osec=krb5 allows user1 access. I'll add the debug line if you could comment on these bits and pieces. Maybe need subtree_check? Thanks. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=777535 https://bugzilla.novell.com/show_bug.cgi?id=777535#c7 --- Comment #7 from Leonardo Chiquitto 2012-08-28 13:30:20 UTC ---

...

To use NFSv4 you need at least to set the fsid (add fsid=0 to the export options). exporting from fsid=0 is no longer needed nor recommended for Linux. Please see the nfs wiki: http://wiki.linux-nfs.org/wiki/index.php/Nfsv4_configuration (last paragraph)

Thanks for the information, I didn't know that.

Mounting the share manually works fine:

mount -t nfs server:/home2/staff /mount-point -osec=krb5 allows user1 access.

Isn't it mounting as v3 here? If I understand correctly, you must something like: # mount -t nfs4 -osec=krb5 server:/home2/staff/dir /mount-point to simulate what AutoFS is actually trying to mount.

I'll add the debug line if you could comment on these bits and pieces.

We need the debug log to see how AutoFS is trying to mount the volume.

Maybe need subtree_check?

Don't know, it's easier to try than to speculate whether it will make a difference or not :) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=777535 https://bugzilla.novell.com/show_bug.cgi?id=777535#c8 lynn wilson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED InfoProvider|lynn@steve-ss.com | --- Comment #8 from lynn wilson 2012-08-29 09:50:44 UTC --- Hi Here is user s10, a member of the group staff SERVER /home2/staff os 0750 root:staff /etc/exports /home2/staff *(rw,sec=sys:krb5,subtree_check) CLIENT /etc/auto.master /home2/staff /etc/auto.staff /etc/auto.master * -rw,sec=krb5,subtree_check SERVER:/home2/staff/& Here is an example session (it's the same at the consol or using su. I used su because it's easier to copy and paste from the Vbox client like this) s10 logs in and expects to get his home directory automounted: steve@hh10:~> su s10 Password: Warning: Your password will expire in 41 days on Tue 09 Oct 2012 05:51:59 PM CEST s10@hh10:/home/steve> cd ~ bash: cd: /home2/staff/s10: No such file or directory Here is the debug log of the same session: Aug 29 11:25:59 hh10 su: pam_krb5[2904]: authentication succeeds for 'steve2' (steve2@HH3.SITE) Aug 29 11:25:59 hh10 su: (to steve2) steve on /dev/pts/1 Aug 29 11:26:49 hh10 su: pam_krb5[2976]: TGT verified using key for 'host/hh10.hh3.site@HH3.SITE' Aug 29 11:26:50 hh10 su: pam_krb5[2976]: authentication succeeds for 's10' (s10@HH3.SITE) Aug 29 11:26:50 hh10 su: (to s10) steve on /dev/pts/1 Aug 29 11:31:34 hh10 automount[3054]: Starting automounter version 5.0.7, master map auto.master Aug 29 11:31:35 hh10 automount[3054]: using kernel protocol version 5.02 Aug 29 11:31:35 hh10 automount[3054]: lookup_nss_read_master: reading master files auto.master Aug 29 11:31:35 hh10 automount[3054]: parse_init: parse(sun): init gathered global options: (null) Aug 29 11:31:35 hh10 automount[3054]: spawn_mount: mtab link detected, passing -n to mount Aug 29 11:31:35 hh10 automount[3054]: spawn_umount: mtab link detected, passing -n to mount Aug 29 11:31:35 hh10 automount[3054]: lookup_read_master: lookup(file): read entry /home2/home Aug 29 11:31:36 hh10 automount[3054]: lookup_read_master: lookup(file): read entry /home2/staff Aug 29 11:31:36 hh10 automount[3054]: master_do_mount: mounting /home2/home Aug 29 11:31:36 hh10 automount[3054]: automount_path_to_fifo: fifo name /run/autofs.fifo-home2-home Aug 29 11:31:36 hh10 automount[3054]: lookup_nss_read_map: reading map file /etc/auto.home Aug 29 11:31:36 hh10 automount[3054]: parse_init: parse(sun): init gathered global options: (null) Aug 29 11:31:36 hh10 automount[3054]: spawn_mount: mtab link detected, passing -n to mount Aug 29 11:31:37 hh10 automount[3054]: spawn_umount: mtab link detected, passing -n to mount Aug 29 11:31:37 hh10 automount[3054]: mounted indirect on /home2/home with timeout 600, freq 150 seconds Aug 29 11:31:37 hh10 automount[3054]: st_ready: st_ready(): state = 0 path /home2/home Aug 29 11:31:37 hh10 automount[3054]: ghosting enabled Aug 29 11:31:37 hh10 automount[3054]: master_do_mount: mounting /home2/staff Aug 29 11:31:37 hh10 automount[3054]: automount_path_to_fifo: fifo name /run/autofs.fifo-home2-staff Aug 29 11:31:37 hh10 automount[3054]: lookup_nss_read_map: reading map file /etc/auto.staff Aug 29 11:31:37 hh10 automount[3054]: parse_init: parse(sun): init gathered global options: (null) Aug 29 11:31:37 hh10 automount[3054]: mounted indirect on /home2/staff with timeout 600, freq 150 seconds Aug 29 11:31:37 hh10 automount[3054]: st_ready: st_ready(): state = 0 path /home2/staff Aug 29 11:31:37 hh10 automount[3054]: ghosting enabled Aug 29 11:31:40 hh10 su: pam_krb5[3062]: TGT verified using key for 'host/hh10.hh3.site@HH3.SITE' Aug 29 11:31:40 hh10 automount[3054]: handle_packet: type = 3 Aug 29 11:31:40 hh10 automount[3054]: handle_packet_missing_indirect: token 25, name s10, request pid 3064 Aug 29 11:31:40 hh10 automount[3054]: attempting to mount entry /home2/staff/s10 Aug 29 11:31:40 hh10 automount[3054]: lookup_mount: lookup(file): looking up s10 Aug 29 11:31:40 hh10 automount[3054]: lookup_mount: lookup(file): s10 -> -rw,sec=sys,subtree_check hh1:/home2/staff/& Aug 29 11:31:40 hh10 automount[3054]: parse_mount: parse(sun): expanded entry: -rw,sec=sys,subtree_check hh1:/home2/staff/s10 Aug 29 11:31:40 hh10 automount[3054]: parse_mount: parse(sun): gathered options: rw,sec=sys,subtree_check Aug 29 11:31:40 hh10 automount[3054]: parse_mount: parse(sun): dequote("hh1:/home2/staff/s10") -> hh1:/home2/staff/s10 Aug 29 11:31:40 hh10 automount[3054]: parse_mount: parse(sun): core of entry: options=rw,sec=sys,subtree_check, loc=hh1:/home2/staff/s10 Aug 29 11:31:40 hh10 automount[3054]: sun_mount: parse(sun): mounting root /home2/staff, mountpoint s10, what hh1:/home2/staff/s10, fstype nfs, options rw,sec=sys,subtree_check Aug 29 11:31:40 hh10 automount[3054]: mount_mount: mount(nfs): root=/home2/staff name=s10 what=hh1:/home2/staff/s10, fstype=nfs, options=rw,sec=sys,subtree_check Aug 29 11:31:40 hh10 automount[3054]: mount_mount: mount(nfs): nfs options="rw,sec=sys,subtree_check", nobind=0, nosymlink=0, ro=0 Aug 29 11:31:40 hh10 automount[3054]: get_nfs_info: called with host hh1(192.168.1.2) proto tcp version 0x30 Aug 29 11:31:40 hh10 automount[3054]: get_nfs_info: nfs v3 rpc ping time: 0.008075 Aug 29 11:31:40 hh10 automount[3054]: get_nfs_info: nfs v2 rpc ping time: 0.001840 Aug 29 11:31:40 hh10 automount[3054]: get_nfs_info: host hh1 cost 4957 weight 0 Aug 29 11:31:40 hh10 automount[3054]: get_nfs_info: called with host hh1(192.168.1.2) proto udp version 0x30 Aug 29 11:31:40 hh10 automount[3054]: get_nfs_info: nfs v3 rpc ping time: 0.002631 Aug 29 11:31:40 hh10 automount[3054]: get_nfs_info: nfs v2 rpc ping time: 0.002170 Aug 29 11:31:40 hh10 automount[3054]: get_nfs_info: host hh1 cost 2400 weight 0 Aug 29 11:31:40 hh10 automount[3054]: prune_host_list: selected subset of hosts that support NFS3 over TCP Aug 29 11:31:40 hh10 automount[3054]: mount_mount: mount(nfs): calling mkdir_path /home2/staff/s10 Aug 29 11:31:40 hh10 automount[3054]: mount_mount: mount(nfs): calling mount -t nfs -s -o rw,sec=sys,subtree_check hh1:/home2/staff/s10 /home2/staff/s10 Aug 29 11:31:40 hh10 automount[3054]: spawn_mount: mtab link detected, passing -n to mount Aug 29 11:31:40 hh10 automount[3054]: >> mount.nfs: access denied by server while mounting hh1:/home2/staff/s10 Aug 29 11:31:40 hh10 automount[3054]: mount(nfs): nfs: mount failure hh1:/home2/staff/s10 on /home2/staff/s10 Aug 29 11:31:40 hh10 automount[3054]: dev_ioctl_send_fail: token = 25 Aug 29 11:31:41 hh10 automount[3054]: failed to mount /home2/staff/s10 Aug 29 11:31:41 hh10 su: pam_krb5[3062]: authentication succeeds for 's10' (s10@HH3.SITE) Aug 29 11:31:41 hh10 automount[3054]: handle_packet: type = 3 Aug 29 11:31:41 hh10 automount[3054]: handle_packet_missing_indirect: token 26, name s10, request pid 3073 Aug 29 11:31:41 hh10 automount[3054]: dev_ioctl_send_fail: token = 26 Aug 29 11:31:41 hh10 su: (to s10) steve on /dev/pts/1 Aug 29 11:31:41 hh10 automount[3054]: handle_packet: type = 3 Aug 29 11:31:41 hh10 automount[3054]: handle_packet_missing_indirect: token 27, name s10, request pid 3062 Aug 29 11:31:41 hh10 automount[3054]: dev_ioctl_send_fail: token = 27 Aug 29 11:31:41 hh10 automount[3054]: handle_packet: type = 3 Aug 29 11:31:41 hh10 automount[3054]: handle_packet_missing_indirect: token 28, name s10, request pid 3062 Aug 29 11:31:41 hh10 automount[3054]: dev_ioctl_send_fail: token = 28 Aug 29 11:31:41 hh10 automount[3054]: handle_packet: type = 3 Aug 29 11:31:41 hh10 automount[3054]: handle_packet_missing_indirect: token 29, name s10, request pid 3079 Aug 29 11:31:41 hh10 automount[3054]: dev_ioctl_send_fail: token = 29 Aug 29 11:31:41 hh10 automount[3054]: handle_packet: type = 3 Aug 29 11:31:41 hh10 automount[3054]: handle_packet_missing_indirect: token 30, name s10, request pid 3079 Aug 29 11:31:41 hh10 automount[3054]: dev_ioctl_send_fail: token = 30 Aug 29 11:31:41 hh10 automount[3054]: handle_packet: type = 3 Aug 29 11:31:41 hh10 automount[3054]: handle_packet_missing_indirect: token 31, name s10, request pid 3079 Aug 29 11:31:41 hh10 automount[3054]: dev_ioctl_send_fail: token = 31 Aug 29 11:31:41 hh10 automount[3054]: handle_packet: type = 3 Aug 29 11:31:41 hh10 automount[3054]: handle_packet_missing_indirect: token 32, name s10, request pid 3079 Aug 29 11:31:41 hh10 automount[3054]: dev_ioctl_send_fail: token = 32 Aug 29 11:31:41 hh10 automount[3054]: handle_packet: type = 3 Aug 29 11:31:41 hh10 automount[3054]: handle_packet_missing_indirect: token 33, name s10, request pid 3079 Aug 29 11:31:41 hh10 automount[3054]: dev_ioctl_send_fail: token = 33 Aug 29 11:31:41 hh10 automount[3054]: handle_packet: type = 3 Aug 29 11:31:41 hh10 automount[3054]: handle_packet_missing_indirect: token 34, name s10, request pid 3079 Aug 29 11:31:41 hh10 automount[3054]: dev_ioctl_send_fail: token = 34 Aug 29 11:31:41 hh10 automount[3054]: handle_packet: type = 3 Aug 29 11:31:41 hh10 automount[3054]: handle_packet_missing_indirect: token 35, name s10, request pid 3079 Aug 29 11:31:41 hh10 automount[3054]: dev_ioctl_send_fail: token = 35 Aug 29 11:31:42 hh10 automount[3054]: handle_packet: type = 3 Aug 29 11:31:42 hh10 automount[3054]: handle_packet_missing_indirect: token 36, name s10, request pid 3079 Aug 29 11:31:42 hh10 automount[3054]: dev_ioctl_send_fail: token = 36 Aug 29 11:31:42 hh10 automount[3054]: handle_packet: type = 3 Aug 29 11:31:42 hh10 automount[3054]: handle_packet_missing_indirect: token 37, name s10, request pid 3079 Aug 29 11:31:42 hh10 automount[3054]: dev_ioctl_send_fail: token = 37 Aug 29 11:31:42 hh10 automount[3054]: handle_packet: type = 3 Aug 29 11:31:42 hh10 automount[3054]: handle_packet_missing_indirect: token 38, name s10, request pid 3079 Aug 29 11:31:42 hh10 automount[3054]: dev_ioctl_send_fail: token = 38 Aug 29 11:31:45 hh10 automount[3054]: handle_packet: type = 3 Aug 29 11:31:45 hh10 automount[3054]: handle_packet_missing_indirect: token 39, name s10, request pid 3079 Aug 29 11:31:45 hh10 automount[3054]: dev_ioctl_send_fail: token = 39 Aug 29 11:31:45 hh10 automount[3054]: handle_packet: type = 3 Aug 29 11:31:45 hh10 automount[3054]: handle_packet_missing_indirect: token 40, name s10, request pid 3079 Aug 29 11:31:45 hh10 automount[3054]: dev_ioctl_send_fail: token = 40 Aug 29 11:31:45 hh10 automount[3054]: handle_packet: type = 3 Aug 29 11:31:45 hh10 automount[3054]: handle_packet_missing_indirect: token 41, name s10, request pid 3079 Aug 29 11:31:45 hh10 automount[3054]: dev_ioctl_send_fail: token = 41 Aug 29 11:34:10 hh10 automount[3054]: st_expire: state 1 path /home2/home Aug 29 11:34:10 hh10 automount[3054]: expire_proc: exp_proc = 3053452096 path /home2/home Aug 29 11:34:10 hh10 automount[3054]: expire_cleanup: got thid 3053452096 path /home2/home stat 0 Aug 29 11:34:10 hh10 automount[3054]: expire_cleanup: sigchld: exp 3053452096 finished, switching from 2 to 1 Aug 29 11:34:10 hh10 automount[3054]: st_ready: st_ready(): state = 2 path /home2/home Aug 29 11:36:08 hh10 automount[3054]: st_expire: state 1 path /home2/staff Aug 29 11:36:08 hh10 automount[3054]: expire_proc: exp_proc = 3053452096 path /home2/staff Aug 29 11:36:08 hh10 automount[3054]: expire_cleanup: got thid 3053452096 path /home2/staff stat 0 Aug 29 11:36:08 hh10 automount[3054]: expire_cleanup: sigchld: exp 3053452096 finished, switching from 2 to 1 Aug 29 11:36:08 hh10 automount[3054]: st_ready: st_ready(): state = 2 path /home2/staff Aug 29 11:36:40 hh10 automount[3054]: st_expire: state 1 path /home2/home Aug 29 11:36:40 hh10 automount[3054]: expire_proc: exp_proc = 3053452096 path /home2/home Aug 29 11:36:40 hh10 automount[3054]: expire_cleanup: got thid 3053452096 path /home2/home stat 0 Aug 29 11:36:40 hh10 automount[3054]: expire_cleanup: sigchld: exp 3053452096 finished, switching from 2 to 1 Aug 29 11:36:40 hh10 automount[3054]: st_ready: st_ready(): state = 2 path /home2/home Question: Why is autofs calling with sec=sys when I have specified sec=krb5 in /etc/auto.staff ? Aug 29 11:31:40 hh10 automount[3054]: mount_mount: mount(nfs): calling mount -t nfs -s -o rw,sec=sys,subtree_check hh1:/home2/staff/s10 /home2/staff/s10 (I still don't think that that's the problem as other users with parent folders of 0755 _can_ mount their home directories. Here is a users steve2 using /etc/auto.home * -rw,sec=krb5,subtree_check SERVER:/home2/home/& In this case it _does_ use krb5 and mounts successfully. Here is the mount output: hh1:/home2/home/steve2 on /home2/home/steve2 type nfs4 (rw,relatime,vers=4.0,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5,clientaddr=192.168.1.41,local_lock=none,addr=192.168.1.2) And here is the log: Aug 29 11:46:11 hh10 automount[3054]: dev_ioctl_send_fail: token = 46 Aug 29 11:46:19 hh10 su: pam_krb5[3143]: TGT verified using key for 'host/hh10.hh3.site@HH3.SITE' Aug 29 11:46:19 hh10 automount[3054]: handle_packet: type = 3 Aug 29 11:46:19 hh10 automount[3054]: handle_packet_missing_indirect: token 47, name steve2, request pid 3144 Aug 29 11:46:19 hh10 automount[3054]: attempting to mount entry /home2/home/steve2 Aug 29 11:46:19 hh10 automount[3054]: lookup_mount: lookup(file): looking up steve2 Aug 29 11:46:19 hh10 automount[3054]: lookup_mount: lookup(file): steve2 -> -rw,sec=krb5,subtree_check hh1:/home2/home/& Aug 29 11:46:19 hh10 automount[3054]: parse_mount: parse(sun): expanded entry: -rw,sec=krb5,subtree_check hh1:/home2/home/steve2 Aug 29 11:46:19 hh10 automount[3054]: parse_mount: parse(sun): gathered options: rw,sec=krb5,subtree_check Aug 29 11:46:19 hh10 automount[3054]: parse_mount: parse(sun): dequote("hh1:/home2/home/steve2") -> hh1:/home2/home/steve2 Aug 29 11:46:19 hh10 automount[3054]: parse_mount: parse(sun): core of entry: options=rw,sec=krb5,subtree_check, loc=hh1:/home2/home/steve2 Aug 29 11:46:19 hh10 automount[3054]: sun_mount: parse(sun): mounting root /home2/home, mountpoint steve2, what hh1:/home2/home/steve2, fstype nfs, options rw,sec=krb5,subtree_check Aug 29 11:46:19 hh10 automount[3054]: mount_mount: mount(nfs): root=/home2/home name=steve2 what=hh1:/home2/home/steve2, fstype=nfs, options=rw,sec=krb5,subtree_check Aug 29 11:46:19 hh10 automount[3054]: mount_mount: mount(nfs): nfs options="rw,sec=krb5,subtree_check", nobind=0, nosymlink=0, ro=0 Aug 29 11:46:19 hh10 automount[3054]: get_nfs_info: called with host hh1(192.168.1.2) proto tcp version 0x30 Aug 29 11:46:20 hh10 automount[3054]: get_nfs_info: nfs v3 rpc ping time: 0.010410 Aug 29 11:46:20 hh10 automount[3054]: get_nfs_info: nfs v2 rpc ping time: 0.002786 Aug 29 11:46:20 hh10 automount[3054]: get_nfs_info: host hh1 cost 6598 weight 0 Aug 29 11:46:20 hh10 automount[3054]: get_nfs_info: called with host hh1(192.168.1.2) proto udp version 0x30 Aug 29 11:46:20 hh10 automount[3054]: get_nfs_info: nfs v3 rpc ping time: 0.007133 Aug 29 11:46:20 hh10 automount[3054]: get_nfs_info: nfs v2 rpc ping time: 0.001830 Aug 29 11:46:20 hh10 automount[3054]: get_nfs_info: host hh1 cost 4481 weight 0 Aug 29 11:46:20 hh10 automount[3054]: prune_host_list: selected subset of hosts that support NFS3 over TCP Aug 29 11:46:20 hh10 automount[3054]: mount_mount: mount(nfs): calling mkdir_path /home2/home/steve2 Aug 29 11:46:20 hh10 automount[3054]: mount_mount: mount(nfs): calling mount -t nfs -s -o rw,sec=krb5,subtree_check hh1:/home2/home/steve2 /home2/home/steve2 Aug 29 11:46:20 hh10 automount[3054]: spawn_mount: mtab link detected, passing -n to mount Aug 29 11:46:20 hh10 automount[3054]: mount_mount: mount(nfs): mounted hh1:/home2/home/steve2 on /home2/home/steve2 Aug 29 11:46:20 hh10 automount[3054]: dev_ioctl_send_ready: token = 47 Aug 29 11:46:20 hh10 automount[3054]: mounted /home2/home/steve2 Aug 29 11:46:20 hh10 su: pam_krb5[3143]: authentication succeeds for 'steve2' (steve2@HH3.SITE) Aug 29 11:46:21 hh10 su: (to steve2) steve on /dev/pts/1 Notice how in this case, sec=krb5 _was_ used Thanks -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=777535 https://bugzilla.novell.com/show_bug.cgi?id=777535#c10 Leonardo Chiquitto changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO InfoProvider| |lynn@steve-ss.com --- Comment #10 from Leonardo Chiquitto 2012-08-29 16:33:42 UTC --- OK. Please do the following test: 1. Stop AutoFS, make sure it's not running 2. Create the destination dirs if needed:

mkdir -p /home2/staff/s10 mkdir -p /home2/home/steve2

3. Try to mount the NFS volumes manually:

mount -t nfs -s -o rw,sec=krb5,subtree_check hh1:/home2/staff/s10 /home2/staff/s10 mount -t nfs -s -o rw,sec=krb5,subtree_check hh1:/home2/home/steve2 /home2/home/steve2

What's the result? 4. Change the permissions of /home2/staff and /home2/home to 750 and repeat the test. What's the result? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=777535 https://bugzilla.novell.com/show_bug.cgi?id=777535#c12 Leonardo Chiquitto changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO InfoProvider| |lynn@steve-ss.com --- Comment #12 from Leonardo Chiquitto 2012-08-29 18:25:23 UTC --- For some reason I thought you were changing the permissions on the client side, not the on server. That made everything more mysterious :) The problem here is that you need to use "no_subtree_check" instead of "subtree_check". That should make it work. By the way, this option is valid on the server only (/etc/exports), so you can remove it from the mount options. I believe this is the explanation (from exports(5) man page): subtree checking is also used to make sure that files inside directories to which only root has access can only be accessed if the filesystem is exported with no_root_squash (see below), even if the file itself allows more general access. Please verify if this works. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=777535 https://bugzilla.novell.com/show_bug.cgi?id=777535#c14 Leonardo Chiquitto changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO InfoProvider| |lynn@steve-ss.com --- Comment #14 from Leonardo Chiquitto 2012-08-30 13:23:45 UTC --- OK, I think I figured it out... This happens because the export option "root_squash" is the default. Meaning that requests coming from the root user (in the client) are translated to "nobody" (in the server). Adding "no_root_squash" to the export options should resolve the problem (but read the man page for the security implications). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=777535 https://bugzilla.novell.com/show_bug.cgi?id=777535#c16 Leonardo Chiquitto changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Autofs will not mount a |Problem mounting an NFS4 |NFS4 share with 0750 |share with 0750 permissions |permissions | --- Comment #16 from Leonardo Chiquitto 2012-08-30 14:27:53 UTC --- Can I have access to this machines? I can't reproduce the problem here. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=777535 https://bugzilla.novell.com/show_bug.cgi?id=777535#c18 Leonardo Chiquitto changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lchiquitto@suse.com AssignedTo|lchiquitto@suse.com |nfbrown@suse.com --- Comment #18 from Leonardo Chiquitto 2012-08-30 15:04:35 UTC --- I don't think it is a bug. We're probably missing some basic NFSv4-specific configuration thing. Neil, could you help? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=777535 https://bugzilla.novell.com/show_bug.cgi?id=777535#c20 --- Comment #20 from lynn wilson 2012-08-31 08:33:11 UTC --- Created an attachment (id=504163) --> (http://bugzilla.novell.com/attachment.cgi?id=504163) tcpdump of a failed mount attempt tcpdump s10 logs out of a failed session and logs back in again. THis should include the failed mount attampt. Where: 192.168.1.2 is the SERVER 192.168.1.40 is the CLIENT -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=777535 https://bugzilla.novell.com/show_bug.cgi?id=777535#c22 Leonardo Chiquitto changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO InfoProvider| |lynn@steve-ss.com --- Comment #22 from Leonardo Chiquitto 2012-09-03 16:18:47 UTC --- Lynn, please use "tcpdump -w nfs.cap -s0 -i ethX" to capture the traffic and then attach the file nfs.cap here. It's easier to analyze the output in binary form. Also, please provide the output of "grep . /proc/sys/net/rpc/*/content" on the server immediately after the mount attempt, as requested by Neil. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=777535 https://bugzilla.novell.com/show_bug.cgi?id=777535#c24 --- Comment #24 from lynn wilson 2012-09-04 02:22:18 UTC --- (In reply to comment #22)

Lynn, please use "tcpdump -w nfs.cap -s0 -i ethX" to capture the traffic and then attach the file nfs.cap here. It's easier to analyze the output in binary form.

Also, please provide the output of "grep . /proc/sys/net/rpc/*/content" on the server immediately after the mount attempt, as requested by Neil.

There isn't the directory you specify: hh1:/home/steve # grep . /proc/sys/net/rpc/*/content grep: /proc/sys/net/rpc/*/content: No such file or directory hh1:/home/steve # cd /proc/sys/net/rpc/ bash: cd: /proc/sys/net/rpc/: No such file or directory Any of these any good? hh1:/home/steve # cd /proc/sys/net hh1:/proc/sys/net # ls bridge core ipv4 ipv6 netfilter unix Thanks -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=777535 https://bugzilla.novell.com/show_bug.cgi?id=777535#c26 --- Comment #26 from lynn wilson 2012-09-04 06:47:51 UTC --- Hey, no problem. I know how you feel. Absolutely no obligation intended. Here is s10 (0750 /home2/staff) logging in unsuccessfully: grep . /proc/net/rpc/*/content /proc/net/rpc/auth.unix.gid/content:#uid cnt: gids... /proc/net/rpc/auth.unix.gid/content:# 4294967295 0: /proc/net/rpc/auth.unix.ip/content:#class IP domain /proc/net/rpc/auth.unix.ip/content:nfsd 192.168.1.40 * /proc/net/rpc/nfs4.idtoname/content:#domain type id [name] /proc/net/rpc/nfs4.idtoname/content:gss/krb5 user 0 root@hh3.site /proc/net/rpc/nfs4.idtoname/content:gss/krb5 group 0 root@hh3.site /proc/net/rpc/nfs4.idtoname/content:gss/krb5 group 21109 staff@hh3.site /proc/net/rpc/nfs4.nametoid/content:#domain type name [id] /proc/net/rpc/nfsd.export/content:#path domain(flags) /proc/net/rpc/nfsd.export/content:/home2/staff *(rw,insecure,root_squash,sync,wdelay,no_subtree_check,uuid=53e45413:19394fbf:96b606d5:bd2eb98b,sec=1:390003) /proc/net/rpc/nfsd.fh/content:#domain fsidtype fsid [path] /proc/net/rpc/nfsd.fh/content:* 7 0x000c062d000000001354e453bf4f3919d506b6968bb92ebd /home2/home /proc/net/rpc/nfsd.fh/content:* 1 0x00000000 / /proc/net/rpc/nfsd.fh/content:* 7 0x000c068f000000001354e453bf4f3919d506b6968bb92ebd /home2/staff /proc/net/rpc/nfsd.fh/content:* 7 0x000c061b000000001354e453bf4f3919d506b6968bb92ebd /home2 Here is steve2 (0755 /home2/home) logging in OK: grep . /proc/net/rpc/*/content /proc/net/rpc/auth.unix.gid/content:#uid cnt: gids... /proc/net/rpc/auth.unix.gid/content:# 4294967295 0: /proc/net/rpc/auth.unix.gid/content:# 3000007 0: /proc/net/rpc/auth.unix.ip/content:#class IP domain /proc/net/rpc/auth.unix.ip/content:nfsd 192.168.1.40 * /proc/net/rpc/nfs4.idtoname/content:#domain type id [name] /proc/net/rpc/nfs4.idtoname/content:gss/krb5 user 3000007 steve2@hh3.site /proc/net/rpc/nfs4.idtoname/content:gss/krb5 user 0 root@hh3.site /proc/net/rpc/nfs4.idtoname/content:gss/krb5 group 0 root@hh3.site /proc/net/rpc/nfs4.idtoname/content:gss/krb5 group 20513 Domain Users@hh3.site /proc/net/rpc/nfs4.idtoname/content:gss/krb5 group 21109 staff@hh3.site /proc/net/rpc/nfs4.nametoid/content:#domain type name [id] /proc/net/rpc/nfsd.export/content:#path domain(flags) /proc/net/rpc/nfsd.export/content:/home2/home *(rw,insecure,root_squash,sync,wdelay,no_subtree_check,uuid=53e45413:19394fbf:96b606d5:bd2eb98b,sec=1:390003) /proc/net/rpc/nfsd.export/content:/home2/staff *(rw,insecure,root_squash,sync,wdelay,no_subtree_check,uuid=53e45413:19394fbf:96b606d5:bd2eb98b,sec=1:390003) /proc/net/rpc/nfsd.fh/content:#domain fsidtype fsid [path] /proc/net/rpc/nfsd.fh/content:* 7 0x000c062d000000001354e453bf4f3919d506b6968bb92ebd /home2/home /proc/net/rpc/nfsd.fh/content:* 1 0x00000000 / /proc/net/rpc/nfsd.fh/content:* 7 0x000c068f000000001354e453bf4f3919d506b6968bb92ebd /home2/staff /proc/net/rpc/nfsd.fh/content:* 7 0x000c061b000000001354e453bf4f3919d506b6968bb92ebd /home2 It seems as if nfs4 is ignoring that s10 is a member of the group staff: steve@hh1:~> id s10 uid=3000009(s10) gid=20513(Domain Users) groups=20513(Domain Users),21109(staff) steve@hh1:~> id steve2 uid=3000007(steve2) gid=20513(Domain Users) groups=20513(Domain Users) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=777535 https://bugzilla.novell.com/show_bug.cgi?id=777535#c28 lynn wilson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED InfoProvider|lynn@steve-ss.com | --- Comment #28 from lynn wilson 2012-09-05 13:00:54 UTC --- cat /etc/exports /home2/home *(rw,sec=sys:krb5,insecure) /home2/staff *(rw,sec=sys:krb5,insecure) /home2/compartida *(rw,sec=sys:krb5,insecure) I changed this to: /home2/staff *(rw,sec=krb5m no_root_squash,insecure) The same. The user logging in does not get his (correctly specified from AD directory)mounted Users in home2/ home mount OK because their mother golder is 0753, not 0750 Thanks -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=777535 https://bugzilla.novell.com/show_bug.cgi?id=777535#c30 --- Comment #30 from lynn wilson 2012-09-05 20:45:33 UTC --- (In reply to comment #29)

After editing /etc/exports, did you run "exportfs -r" ??

You need to run "exportfs -r" for any changes to /etc/exports become effective.

I restart the nfs server: rcnfsserver restart I also tried with with exportfs -r. Same resukts. Thanks, -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=777535 https://bugzilla.novell.com/show_bug.cgi?id=777535#c32 lynn wilson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED InfoProvider|lynn@steve-ss.com | --- Comment #32 from lynn wilson 2012-09-06 10:01:52 UTC --- Hi Neil My fault. The LAN was busy and I had to walk between the client and the server. I got in on Vbox now: Server cat /etc/exports /home2/home *(rw,sec=sys:krb5,insecure) /home2/staff *(rw,sec=sys:krb5,insecure) ls -l /home2 total 16 drwxrwsr-x+ 2 root Domain Users 4096 Sep 1 13:33 compartida drwxr-xr-x 4 root root 4096 Sep 1 09:17 home drwxrwxrwt 3 root root 4096 Aug 29 12:41 profiles drwxr-x--- 3 root staff 4096 Sep 1 09:17 staff ps aux | grep rpc root 599 0.0 0.0 2648 856 ? Ss 11:04 0:00 /sbin/rpcbind -w -f root 1814 0.0 0.0 0 0 ? S< 11:04 0:00 [rpciod] root 1846 0.0 0.0 4092 172 ? Ss 11:04 0:00 /usr/sbin/rpc.gssd root 1862 0.0 0.0 2888 160 ? Ss 11:04 0:00 /usr/sbin/rpc.idmapd root 10164 0.0 0.0 4016 1108 ? Ss 11:28 0:00 /usr/sbin/rpc.svcgssd statd 10173 0.0 0.0 2828 1068 ? Ss 11:28 0:00 /usr/sbin/rpc.statd --no-notify root 10174 0.0 0.0 3276 804 ? Ss 11:28 0:00 /usr/sbin/rpc.mountd root 10604 0.0 0.0 4176 800 pts/0 S+ 11:52 0:00 grep --color=auto rpc Client cat /etc/auto.master /home2/home /etc/auto.home /home2/staff /etc/auto.staff cat /etc/auto.home * -sec=krb5 hh1:/home2/home/& cat /etc/auto.staff * -sec=krb5 hh1:/home2/staff/& ps aux | grep rpc root 364 0.0 0.2 2648 1100 ? Ss 11:20 0:00 /sbin/rpcbind -w -f root 1706 0.0 0.0 0 0 ? S< 11:21 0:00 [rpciod] root 1763 0.1 0.0 4092 428 ? Ss 11:21 0:03 /usr/sbin/rpc.gssd root 1783 0.0 0.0 2888 384 ? Ss 11:21 0:00 /usr/sbin/rpc.idmapd root 2795 22.2 0.1 4176 796 pts/1 S+ 11:54 0:00 grep --color=auto rpc id steve2 uid=3000007(steve2) gid=20513(Domain Users) groups=20513(Domain Users) id s10 uid=3000009(s10) gid=20513(Domain Users) groups=20513(Domain Users),21109(staff) Why can we only export 0755 (or worse) shares. I believe this to be a NFS4 limitation. I have just got our Ubuntu guy to reproduce it on 12.04. Thank you so much for not throwing this one out. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=777535 https://bugzilla.novell.com/show_bug.cgi?id=777535#c34 lynn wilson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED InfoProvider|lynn@steve-ss.com | --- Comment #34 from lynn wilson 2012-09-13 07:02:38 UTC --- We tried mounting no_root_squash and it still will not mount a 0750 share the way we need it In a college with over 2000 students sharing 200 computers nfsd is right at the top of the process list, often taking 90% CPU. That is with /home2 mounted permanently on home2 I can relive some of the burden by using wildcards: * -rw,sec=krb5 /home2/year7a/& This will mount only one folder if only one student is logged in and only works for 0755 folders. My problem is with the /home2/staff folder which is 0750. Here I cannot do the same as with the students. I have to mount the whole of the folder all of the time. 100 teacher folders mounted when only one is working. I have to have the extrasecurity on the staff folder as it contains confidential information. If I wat to do the same, I must use NFS3 Are you saying that I should not use the automounter? If I don't, as the lan gets busy it gets slower and slower. Is NFS4 intended to be a replacement to NFS3? Thanks -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=777535 https://bugzilla.novell.com/show_bug.cgi?id=777535#c36 lynn wilson changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED InfoProvider|lynn@steve-ss.com | --- Comment #36 from lynn wilson 2012-09-13 16:15:22 UTC --- (In reply to comment #35)

I'm absolutely sure that no_root_squash will make it work for you. It is exactly the thing that is causing the problem. You haven't yet convinced me that you have correctly tried it. If you can show me that "/proc/fs/nfsd/exports" contains the "no_root_squash" flag and it still isn't working, we can pursue that avenue further.

OK. Again: Server: hh1:/home/steve # cat /etc/exports /home2/home *(rw,sec=krb5) /home2/staff *(rw,sec=krb5,no_root_squash) /home2/compartida *(rw,sec=krb5) hh1:/home/steve # rcnfsserver restart redirecting to systemctl Client hh10 login: s10 Password: Last Login Thu Sep 13 17:48:38 on tty2 -- s10 : /home2/staff/s10: change directory failed: No such file or directory Logging in with home = "/" s10@hh10:/> Back on the server: hh1:/home/steve # cat /proc/fs/nfsd/exports # Version 1.1 # Path Client(Flags) # IPs /home2/staff *(rw,no_root_squash,sync,wdelay,no_subtree_check,uuid=86b8cab0:beef4c0f:b9477b39:f160430c,sec=390003) / *(ro,root_squash,sync,no_wdelay,no_subtree_check,v4root,fsid=0,uuid=86b8cab0:beef4c0f:b9477b39:f160430c,sec=390003) /home2 *(ro,root_squash,sync,no_wdelay,no_subtree_check,v4root,uuid=86b8cab0:beef4c0f:b9477b39:f160430c,sec=390003) Does this give us any more clues? Thank you for your suggestions. I have trioed to answer them inline but I feel these are apart from this issue (nonetheless I would be most grateful if your could spare me any off list time to help me with these)

I cannot see why you think the wildcard automount map would reduce the burden on the NFS server. It won't reduce the amount of traffic in any way. Just having something mounted isn't a burden. Only the actual accesses cause any load and they will be the same no matter how things are mounted.

You should use the automounter for the top level directory - much better than a hard mount in /etc/fstab. However NFSv4 has internal 'automount' support. If you just mount "/", or "/foo" or whatever, then any filesystems below there (that have been exported) will automatically get mounted when they are used.

I have tried both fstab and the automounter. The automounter wins hands doen ¡n over the fstab but . . .

I'm really perplexed by your statement that the lan gets busy and slows down. Do you have any idea what sort of traffic is slowing it down?

Art and design students using big jpgs between cifs and nfs. We have a Samba 4 domain (it's a lot worse with 2008R2) and it is the transfer of large files that is the problem. The DC is separate and we have a big box serving both cifs to the m$ clients and nfs for openSUSE. As I say, this is not the issue of the bugzilla. Before you ask, using only Linux boxes is the same. If I automount the home/students/<name> directory it works instantaneously. Unless, of course the art class is in. If I mount the whole of /home2/students is much slower.

NFSv4 is certainly meant to be a replacement for NFSv3. It does not behave exactly the same way in all cases. Hopefully it is better in most cases, but you have found a corner case where it is (arguably) not as "good". But I think it is a corner that can be avoided.

(presumably the individual directories in /home2/staff do not give world access? In that case it doesn't really matter if /home2/staff does. Or do you not trust staff to keep their directories secure? I guess that could be an issue).

I understand you perfectly but I _must_ have the staff directory at 0750 to stop students entering. Once again, this is not really the subject of this bugzilla but I welcome your support and suggestions. In cifs on m$ this works perfectly. On m$ staff can enter without problems by whichever mechanism cifs uses. It is also very economical on the fileserver. So there you have it. 1001 issues each with his own opinion on what should be done in one single bugzilla. Let's please concentrate on why the 0750 share will not automount, the title of this bug. Cheers and thanks so much for your input, honesty and time. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=777535 https://bugzilla.novell.com/show_bug.cgi?id=777535#c38 --- Comment #38 from lynn wilson 2012-09-17 11:19:30 UTC --- (In reply to comment #37)

OK, I believe you now :-) I've even managed to reproduce it. It only happens when using krb5.

When

using 'sys' it works as I expected.

Correct. It also works with kerberized NFS3

It seems that with krb5 the client walks down the mount path as some unprivileged user which I haven't discovered the exact details of yet (kerberos is still a bit of a black box to me). So no_root_squash has no effect on it. Oh well....

We don't really use root with Kerberos. The user who has authenticated already has tickets at the point he tries to access home directory and therefore _should_ de allowed access.

I'll try to pursue this with the upstream developers as it does seem like a regression. I don't have a lot of confidence that I will get a result though as the intended use of NFSv4 is to just mount '/' and walk down from there, which works.

This is the main point of the bug so thank you so much for taking this up for me.

You say it doesn't work for you due to performance issues and I'd really like to understand that as I now think that it the best way for you to get a working configuration.

Mounting /home2 using fstab using fstab is a disaster. Forget it. Mounting it using autofs gives us a reasonable boot and logon time until we start throwing large jpg's around. I can ease the situation by splitting the /home2/students folder into home2/class1, /home2/class2, /home2/class3 and automounting * -sec=krb5 hh1:/home2/& always assuming of course that class1, class2 and class3 have 0755 permissions. The staff folder is less of a problem as it only contains around 100 users (but still needs to be 0750 staff)

You say that the performance problems are caused by students moving large jpeg files around. I can certainly imagine that might cause slowness, but I cannot see how there would be more of that if you mounted "/home2" rather than "/home2/student/$USERNAME".

It maybe because if I mount /home2, I am mounting over 2000 home folders all at the same time. If I mount just one, then surely that would improve performance. The NFS server has only one mounted folder to look after.

That exactly is it that is slower? It it the act of performing the mount, or is it all the file access one the filesystem has been mounted?

Please see the examples above amount what is slower. I really don't know. Logging in and loading a jpeg over nfs4 takes about the same time as logging in to W7 over cifs, but please remember, interesting though it is, the main bug is the non mount woth 0750 permissions Thanks Neil for your time and interest. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=777535 https://bugzilla.novell.com/show_bug.cgi?id=777535#c40 --- Comment #40 from Neil Brown 2012-09-18 00:45:11 UTC --- Thanks for the extra information. I think I have a better idea of what is happening. When you mount /home2 you are not mounting over 1000 home folders at the same time - you really are just mounting one folder (which happens to contain over 1000 subfolders). However if anyone does "ls -l /home2" or a similar operation, that could well cause serious performance issues. GUI file browsers have a tendency to do things like this so maybe some app that the students are using is occasionally doing something like "ls -l /home2" and causing the problem. Just mounting the homes that you need would significantly reduce the cost of these "ls -l" equivalents. I've been thinking about how to present an argument to upstream developers for some sort of change, but not only have I failed to come up with a credible change, I've also failed to come up with a strong argument. You see: if you allow any NFS client to mount /home2/staff/user1, then you are already bypassing the permissions on /home2/staff. Anyone on the client can access that directory without any reference to the permissions on /home2/staff. You could set them to anything you like and it wouldn't affect who can access the directory. Only the permissions on the automount directories on the client affect access control. Given that is the case, you may as well set /home2/staff/user1 to 0751. Put another way: If you never mount /home2/staff on the clients, then the permissions of that directory have no impact at all on applications on the clients. Do you ever have non-staff logging directly in to the file server? If you don't, and if you never mount /home2/staff onto clients, then restricting /home2/staff to "0750" is completely pointless - it won't affect anyone. So I still think the best solution is to chmod /home2/staff to '751'. Another options is to 'chgrp nogroup /home2/staff'. That will allow 'mount' to access the subfolders but will keep students out (assuming they can even get that close). Another option is to sub-divide each directory so you never have more than a dozen or so folders in one directory. That might be a bit of a pain though. I'm sorry but I really don't think we can change the current behaviour of NFS. The more I think about it, the more I am convinced that the current behaviour is *right*. The old behaviour could give away access which it shouldn't. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=777535 https://bugzilla.novell.com/show_bug.cgi?id=777535#c42 --- Comment #42 from Neil Brown 2012-09-18 01:23:12 UTC --- Hey .. I just had another thought. If the performance problem is related to something doing something like ls -l /home2 then you could avoid that by removing read permission from /home2 and /home2/staff and /home2/student. i.e. "chmod go-r directoryname". That would ensure no "ls -l" causes problems. It might cause other problems, I don't know. But it could be worth the experiment. i.e. use the automounter to just mount /home2, and remove read access from /home2 and all child directories down to (but not including) individual home directories. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=777535 https://bugzilla.novell.com/show_bug.cgi?id=777535#c lynn wilson changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P3 - Medium |P4 - Low -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=777535 https://bugzilla.novell.com/show_bug.cgi?id=777535#c45 --- Comment #45 from Neil Brown 2012-09-27 02:25:06 UTC --- No, rpc.gssd appear to be working correctly. Everything is behaving exactly as it is designed to do. Unfortunately your use case doesn't fit into that design. You only options are to give up some requirement. - use NFSv3 - mount /home2/staff rather than /home2/staff/$USER - chmod a+x /home2/staff Sorry, but there really isn't anything here to be fixed. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.