Solved NFSv4 without Kerberos

Hello everyone!

I'm trying to build diskless system with some mounts done by NFSv4, and i can't figure out how to mount share without kerberos, with -sec=sys flavour. Doing all by handbook, on server i have:

server's /etc/rc.conf:
Code:
ifconfig_em1="inet 10.101.0.1/24"
nfs_server_enable="YES"
nfsuserd_enable="YES"
nfsv4_server_enable="YES"
server's /etc/exports
Code:
/mnt/diskless10 -network 10.101.0 -mask 255.255.255.0
V4: /mnt/v4share -sec=sys -network 10.101.0 -mask 255.255.255.0

client's /etc/rc.conf:
Code:
nfsuserd_enable="YES"
nfscbd_enable="YES"

Client is diskless, mounted /mnt/diskless10 as read-only NFS root, system is booted just fine. Trying to mount NFSv4 share from server:
Code:
root@netboot_v4: ~# mount_nfs -o nfsvers=4 10.101.0.1:/mnt/v4share /var/mnt
[tcp] 10.101.0.1:/mnt/v4share: Permission denied

In the server's /var/log/messages:
Code:
Aug 14 21:06:58 virt mountd[7392]: mount request denied from 10.101.0.20 for /mnt/v4share

I don't understand why it's denied, there is no other messages. Tried to search web and this forum, no luck - there's stories about successful mount in kerberized environment (and me myself got this done at another place, mounted share from FreeBSD on Ubuntu by NFSv4 just fine), but i don't want kerberos complexity in this system.
 
To define a range of permitted IP adresses in /etc/exports you have do define them either like -network 10.101.0/24 or use wildcards like -network 10.101.0.*/?. See exports(5).
You see Permission denied because what you currently have is not a valid IP adress or range.
 
-network 10.101.0, you're missing a digit.
To define a range of permitted IP adresses in /etc/exports you have do define them either like -network 10.101.0/24 or use wildcards like -network 10.101.0.*/?. See exports(5).
You see Permission denied because what you currently have is not a valid IP adress or range.
No, i'm not missing a digit and this is valid IP range - see exports(5), in EXAMPLES:

Code:
      /u -maproot=bin: -network 131.104.48    -mask 255.255.255.0
       V4: /   -sec=krb5:krb5i:krb5p -network 131.104.48 -mask 255.255.255.0

If there would be syntax error in network definition, diskless client would not boot from this share, but it does boot, and NFSv3 mount works.

Even with this line
Code:
V4: /mnt/v4share -sec=sys -network 10.101.0.0/24
share is not mounted.
 
quoting the manpage:
Code:
    In the following example some directories are exported as NFSv3 and
     NFSv4:

           V4: /wingsdl/nfsv4
           /wingsdl/nfsv4/usr-ports -maproot=root -network 172.16.0.0 -mask 255.255.0.0
           /wingsdl/nfsv4/clasper   -maproot=root clasper

     Only one V4: line is needed or allowed to declare where NFSv4 is rooted.
     The other lines declare specific exported directories with their absolute
     paths given in /etc/exports.

     The exported directories' paths are used for both v3 and v4.  However,
     they are interpreted differently for v3 and v4.  A client mount command
     for usr-ports would use the server-absolute name when using nfsv3:

           mount server:/wingsdl/nfsv4/usr-ports /mnt/tmp

     A mount command using NFSv4 would use the path relative to the NFSv4
     root:

           mount server:/usr-ports /mnt/tmp
Try with
Code:
mount_nfs -o nfsvers=4 10.101.0.1:/ /var/mnt
 
Try with
Code:
mount_nfs -o nfsvers=4 10.101.0.1:/ /var/mnt
Yes, I know about this and i've tried to mount 10.101.0.1:/ with same result - permission denied. On the NFS host in /var/log/messages I see:

Code:
Aug 14 22:59:13 virt mountd[7392]: mount request denied from 10.101.0.20 for /

Seems that I should write to freebsd-net mailing list.
 
It's a silly thing, but i found the problem: it should be not
Code:
mount_nfs -o nfsvers=4 10.101.0.1:/ /var/mnt
but
Code:
mount_nfs -o nfsv4 10.101.0.1:/ /var/mnt

But in the process kind man Rick Macklem wrote his summarized experience, which i think would be useful to other:

Code:
Just fyi, there are a couple of things (particularily if you are using an NFSv4 mounted
root):
1 - setting the sysctls
      vfs.nfsd.enable_stringtouid=1
      vfs.nfs.enable_uidtostring=1
      Allows the uid/gid to be put in the Owner/Owner_group string as a number
     (ie "1001"). This avoids any need to run the nfsuserd if all mounts are sec=sys.
     This is now the default for most Linux distros.

     Even if you want to run the nfsuserd, it won't be working until the system is
     booted. (If you don't do the above, all the files needed to get booted must be
     world read/exec.)

2 - A Kerberized root mount won't work, because the gssd must be running for
     Kerberos access to work and that can't happen until booted.

....

There is:
sysctl vfs.nfsd.debuglevel
for the server and
sysctl vfs.nfs.debuglevel
for the client side.
--> If you set these > 0, stuff gets kernel printf()d, which will normally
      end up in /var/log/messages.
      --> The larger the number, the chattier it gets. By the time you go to "4", it
            generates lots of stuff.
Is that stuff useful? Well, it is to me, but I'm not sure it helps users much.
(If you look in the kernel sources for NFSD_DEBUG() and NFSCL_DEBUG(), you
 can find where the stuff is generated.)
 
Back
Top