Repository navigation
unfs3 probably broken #127
Description
Activity
This is an unfortunately complicated problem.
If you attempt to use the standard NFS port (2049), unfs3 will create a regular BSD style TCP socket and bind it to the specified port. It will then pass that file descriptor to
svctcp_create(), part of the RPC suite of functions. On Solaris and illumos systems, that function comes fromlibnsl.so.1and appears to require not a BSD socket but a TLI socket, an unfortunate remnant of UNIX history.Note in the autoconf scripts for unfs3 there is a mention of
librpcsoc.so.1, one of the SunOS/UCB compatibility libraries that we don't ship in SmartOS. This library contains an implementation ofsvctcp_create()which does allow the use of BSD sockets. I believe that theconfigurescript doesn't end up using it for our pkgsrc build because it's not available on the system, but the behaviour you see above is then only visible at runtime.One way to work around this, though it's not perfect (because it involves the use of dynamic port numbers which confuses at least the Linux NFS client) is to use the
-uflag to unfsd. This will use a random port for the NFS and MOUNT services; i.e., it passesRPC_SOCKANYrather than a specific file descriptor, so there is no socket type mismatch.There are two likely paths forward for this issue:
- fix illumos to accept BSD sockets as well as TLI sockets for the RPC functions, though this means
unfsdwill still be broken until you upgrade to a platform image with this fix - fix
unfsdto be able to create and bind a TLI socket instead of a BSD socket, which would mean we can useunfsdeven on older illumos systems in advance of this fix
There's a third option, which is probably also not great, which is to create a pkgsrc package with the
librpcsoc.so.1compatibility bits in it and ship it outside the core OS -- but I don't know how hard it would be to extricate it from illumos-gate and build it elsewhere, or if it makes use of private interfaces with the rest of the OS.- fix illumos to accept BSD sockets as well as TLI sockets for the RPC functions, though this means
Note in particular that the compatibility
librpcsoc.so.1contains what appear to be wrappers around the core RPC functionality fromlibnsl.so.1; e.g., see https://github.com/joyent/illumos-joyent/blob/master/usr/src/ucblib/librpcsoc/svc_tcp.c#L87-L168This function calls at least
svc_xprt_alloc()which does not seem to be documented, andxprt_register(), which does. Some more digging would be required to see how safe it would be to ship a copy of this library in pkgsrc.I actually tried specifying a udp port but that did not help. This is probably related why some packages no longer build without patching because they can't find rpcgen on newer platforms. (See #126) Maybe it is worth wrapping some of the remove bits up in an optional package somehow.
@sjorge Specifying a port won't help, because from the perspective of the RPC routines the same thing is happening. Whether
unfsdattempts to use its specific default (2049), or whether you provide a specific port, in both casesunfsdis binding a BSD style socket and attempting to pass it to the RPC routines, which doesn't work for the reason I described above.If instead you use the
-uflag I mentioned, the software will passRPC_SOCKANYto get a random port number. From the manual page:-u Use an unprivileged port for NFS and MOUNT service. Normally, unfsd will use port number 2049, which is the standard port for NFS. When this option is in effect, arbitrary ports chosen by the RPC library will be used. You may need to use this option when running unfsd from a normal user account.This is not related to
rpcgen-- rather, it's a long-standing issue withunfsdwhen built against the regularlibnsl.so.1RPC routines. As far as I know, we've never shipped the ancient compatibilitylibrpcsoc.so.1in the SmartOS platform image so this problem has existed in theunfsdpackage since we started shipping pkgsrc packages.- added a commit that references this issue
on Sep 24, 2018 - added a commit that references this issue
on Nov 29, 2018 - added a commit that references this issue
on Dec 10, 2018 - added a commit that references this issue
on Oct 20, 2019 - added a commit that references this issue
on Jan 3, 2020 - added a commit that references this issue
on Mar 11, 2020 - added 2 commits that reference this issue
on Mar 25, 2020 94 remaining items
- added 4 commits that reference this issue
on May 22, 2026 - added a commit that references this issue
on May 24, 2026 - added 2 commits that reference this issue
on Jul 26, 2026 - added a commit that references this issue
on Aug 26, 2026 - added a commit that references this issue
on Sep 12, 2026
Looks like unfs3 package is broken on Solaris
Is all that is logged and it does not appear to start.