> On Nov 9, 2023, at 9:42 PM, Cedric Blancher <cedric.blancher@xxxxxxxxx> wrote: > > On Fri, 10 Nov 2023 at 03:19, Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote: >> >> >> >>> On Nov 9, 2023, at 7:47 PM, Cedric Blancher <cedric.blancher@xxxxxxxxx> wrote: >>> >>> On Fri, 10 Nov 2023 at 01:37, Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote: >>>> >>>>> On Nov 9, 2023, at 7:05 PM, Cedric Blancher <cedric.blancher@xxxxxxxxx> wrote: >>>>> >>>>> On Thu, 2 Nov 2023 at 10:51, Cedric Blancher <cedric.blancher@xxxxxxxxx> wrote: >>>>>> >>>>>> Good morning! >>>>>> >>>>>> Does anyone have examples of how to use the refer= option in /etc/exports? >>>>> >>>>> Short answer: >>>>> To redirect an NFS mount from local machine /ref/baguette to >>>>> /export/home/baguette on host 134.49.22.111 add this to Linux >>>>> /etc/exports: >>>>> >>>>> /ref *(no_root_squash,refer=/export/home@134.49.22.111) >>>>> >>>>> This is basically an exports(5) manpage bug, which does not provide >>>>> ANY examples. >>>> >>>> That's because setting up a referral this way is deprecated. >>> >>> Why did you do that? >> >> The nfsref command on Linux matches the same command on Solaris. > > That does not answer my question. Why did you declare the refer option > in exports(8) depreciated, where it works, and is a much simpler way > than nfsref. nfsref information has to be maintained in yet another > configuration file, and nfsd on Linux already has TOO MANY of them. > Leave alone the fact that there is no Solaris-style INTRO manpage, > which systematically links all config files for nfsd, and all daemons > like rpc.gssd. > > The all-in-one /etc/exports and /etc/exports.d/ sounds like a better solution. There's no plan to remove refer= and replica=. We just prefer that folks use nfsref because junctions are a richer, more capable, mechanism than export options. You are welcome to contribute examples to exports(5). >> nfsref was added years ago to manage junctions, as part of FedFS. >> The "refer=" export option can't do that... and FedFS has gone >> the way of the dodo. > > Can NFSv4 clients create junctions? Or just tools on the server side? There is no capability in the NFSv4 protocol to create or modify junctions. The NFSv4 protocol exposes a redirection to clients by means of GETATTR(fs_locations) -- clients don't see the junction object itself. A separate protocol, described in RFC 7533, is used for managing junctions remotely. There are some tools to do this on Linux, but there has been no demand for this so they are not packaged. In addition, a junction object in a filesystem can be converted atomically from a directory with entries to a junction and back. That's difficult to do with lines in /etc/exports. This is why we prefer nfsref. >>> The configure switch in nfs-utils to build it is OFF by default, >> >> You're talking about >> >> --enable-junction enable support for NFS junctions [default=no] > > YES, that nightmare. > > Nightmare, as it suddenly makes nfs-common depend on libidn11-dev > libcap-dev libldap-dev libsqlite3-dev libxml2-dev liburiparser-dev > libconfig-dev libdevmapper-dev and other packages. Package maintainer > hell. Several of those have nothing to do with nfsref. That's just what it takes to build nfs-utils. It's always been like that. Can you say exactly what is pulling in the LDAP dependency? I recall removing all of the LDAP stuff when I added nfsref to nfs-utils because we wanted to avoid adding an LDAP requirement. -- Chuck Lever
