danmcd andyf so nfs under lx was special too right?

It still seems to fail with an IPv6 address but I get a different error now

AH yes

16809 mount.nfs setsockopt(41, 72)\0

Now to figure out what 72 is

IPV6_<something> given proto is 41

Hmmm nothing in lx_socket.h for that it seems

github.com/freebsd/freebsd-src/blob…linux/linux_socket.h#L309C1-L309C39 perhaps

What's funny is that the option in question was written in this RFC: rfc-editor.org/rfc/rfc5014

By former Sun TCP/IP DE Erik Nordmark.

Funnier still is that FreeBSD, per your link, treats it like a dead option.

sjorge: yea it was special in some way iirc. I believe it was using the native nfs bits to mount rather than using what's in linux

it's linux mount.nfs throwing the unsup dtrace probe

it seems lx does mostly replace the lockd stuff, possibly more, but it does look like mount.nfs does stuff before handing it to the kernel

danmcd_: or papertigers so you happen to know how the stuck maps work in the lx socket code? ours does not go that high, so it might be returning some default error instead of a cleaner not supported one? i find the code confusing as we also have a switch for some marked as unsup in the struct

I would have to pull up the source...but I remember doing work in the code that spawned something called lx_mountd maybe

I take it you have already seen github.com/TritonDataCenter/illumos…/lx/lx_brand/common/mount_nfs.c#L13

and I was thinking of lx_lockd not mountd sorry