Description of problem: Per the example given in the man page, I expect a <client>(<export options>) paring of the form "*(sec=krb5)" listed in /etc/exports to require krb5 security for the clients that matched the wildcard. Excerpted from "man 5 exports": > ... Each listed client may be immediately followed by a parenthesized, comma-separated list of export options for that client. ... > ... > # sample /etc/exports file > ... > /srv/www -sync,rw server @trusted @external(ro) > ... > ... The sixth line exports a directory read-write to the machine 'server' as well as the `@trusted' netgroup, and read-only to netgroup `@external', all three mounts with the `sync' option enabled. ... > ... --------------------------- Following are the results of my attempt to export a "test" share with sec=sys:krb5 to the "trusted" client but sec=krb5 to anyone else. SERVER with *(sec=krb5): [root@nfs ~]# cat /etc/exports /export -fsid=0,sec=sys:krb5,ro,no_root_squash * /export/test -fsid=1,rw,no_root_squash trusted *(sec=krb5) [root@nfs ~]# exportfs -rv exporting trusted:/export/test exporting *:/export/test exporting *:/export CLIENT: [root@untrusted ~]# mount nfs.cs.siue.edu:/test /mnt [root@untrusted ~]# ls /mnt dir1 dir2 dir3 [root@untrusted ~]# mount nfs.domain:/test on /mnt type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=XXX.XXX.XXX.XXX,local_lock=none,addr=YYY.YYY.YYY.YYY) In the above trial run, the "untrusted" client was able to mount the test share without any kerberos credentials. This is not what I expected and it may be a bug. --------------------------- Following are the results of removing "*(sec=krb5)" from /etc/exports on the server and remounting the "test" share from the "untrusted" client. The client is not able to list the contents of the filesystem, as expected. SERVER without *(sec=krb5): [root@nfs ~]# cat /etc/exports /export -fsid=0,sec=sys:krb5,ro,no_root_squash * /export/test -fsid=1,rw,no_root_squash trusted [root@nfs ~]# exportfs -rv exporting trusted:/export/test exporting *:/export CLIENT: [root@untrusted ~]# mount nfs.cs.siue.edu:/test /mnt [root@untrusted ~]# ls /mnt [root@untrusted ~]# mount nfs.domain://test on /mnt type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=XXX.XXX.XXX.XXX,local_lock=none,addr=YYY.YYY.YYY.YYY) SERVER: [root@nfs ~]# rpm -q nfs-utils nfs-utils-1.2.8-2.0.fc19.x86_64 CLIENT: [root@untrusted ~]# rpm -q nfs-utils nfs-utils-1.2.8-6.3.fc19.x86_64
Is there a mountpoint at /export/test? (So, is /export/test on a different filesystem from /export/? Relevant output from "mount" or "findmnt" on the server side might be interesting.) Also, contents of the server-side files /proc/net/rpc/*/content might be interesting.
I've since updated my server to kernel-3.14.15-100.fc19.x86_64 and nfs-utils-1.2.8-6.3.fc19.x86_64. I'm now getting "mount.nfs: an incorrect mount option was specified" when I run the mount command on the client (I'm not specifying any mount options). If I add "-o sec=sys" I get "access denied by server ...". If I add "-o sec=krb5" I get the "an incorrect mount option ..." error. I guess the bug was particular to the older version of nfs-utils and/or the kernel. FYI, /export/test was mounted from a zfs filesystem and /export was on the root ext4 filesystem. Sorry for reporting the bug against an outdated package. I'll let you close out the bug because I'm not sure how it should be filed. Thanks, gb
P.S. I think the kernel version was kernel-3.11.8-200.fc19.x86_64 when the problem first occurred. FYI, gb
Hm, OK, well, closing, but feel free to reopen or open another bug if needed for the "incorrect mount option" problem.