Several NFS errors on diskless clients

[Rick Macklem]

Beeblebrox wrote:
> I have some errors I'm unable sort on my PXE-booting diskless
> clients.
> 
> 1. ACL for NFS-V4 confuses jailed clients:
> Root for diskless clients is served from jail, which basically can
> only serve dhcp and tftp. Since NFS can't be jailed, it is served
> from host.
> * It seems root cannot be mounted as V4 and is limited to V2. Thus
> the /etc/exports file:
> {/data/amd64 -ro -network 192.168.2.0/26  # folder where jail resides
> V4:   /
> /usr/local  -ro -network 192.168.2.0/26
> /home           -network 192.168.2.0/26}
> * The client /etc folder is served from
> /data/amd64/conf/base/etc.cpio.gz, and it is a copy of host /etc.
> * listing contents of mounted V4 folders (/home or /usr/local) shows
> a number rather than user ID, but client etc/*pwd.db and etc/group
> are all exact copies of what is on host. This causes user-ID
> problems for my setup.
> Is there a solution to this?
> 
Nope, a diskless root fs is not supported by NFSv4. There are a couple
of reasons:
1 - The root fs can't map between uid/gid#s<->user/group names. Recent
    changes to NFSv4 does allow a uid/gid# in the owner/owner_group
    string. As such, I think this can work if the server has:
    vfs.nfsd.enable_stringtouid=1 and nfsuserd not running, such that
    only uid/gid#s are in the strings.
2 - The client needs a unique uuid string to identify the client uniquely.
    (That uuid won't be available when the client first boots.)
    I don't know a good solution for this. (Basically the client must
    have a unique identifier string. A simplistic implementation using
    something like the MAC and IP address of the client's network
    interface (the one used to get to the NFS server) might work?
3 - The client needs a file handle for the root dir. For some servers,
    including FreeBSD's, it is the same as the NFSv3 file handle.
    However, if it isn't the same, none of the boot code, which does
    NFSv2 or NFSv3 knows how to get it.
--> Until these are resolved, a diskless NFSv4 root fs isn't
    going to work.

> 2. For de-bugging, I reverted all exports to V2/3. Then, (although I
> probably don't need it) I do "service hald onestart" (dbus has
> already been started)
> "nfs_getpages: error 13
> vm_fault: pager read error, pid 652 (dbus-daemon-launch-)
> nfs_getpages: error 13
> vm_fault: pager read error, pid 664 (dbus-daemon-launch-)"
> How significant is this error?
> 
For some reason, it can't page the file in, so I'd assume that executable isn't
going to work. 13 is EACCES, so the client read of this is failing,
due to an access error.
One possibility would be that the pagein is being done by root and
that is being mapped to "nobody" and failing, due to lack of world
read/execute permission on the file.
Try adding -maproot=root to the export line on the server for this
file system or maybe adding r-x for world to the file's mode might fix it.
Without looking at the packet trace, it is hard to guess what uid
the client would be using to do the page-in. (root maybe?)

rick

> 3. Client rc.conf setting is unable to start these services (not so
> on host):
> dbus_enable="YES"
> distccd_enable="YES" \ distccd_flags="-a 192.168.2.1"
> 
> Thanks and regards.
> 
> --
> FreeBSD_amd64_11-Current_RadeonKMS
> _______________________________________________
> freebsd-fs at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"
>