> On Jan 29, 2024, at 10:07 AM, Roland Mainz <roland.mainz@xxxxxxxxxxx> wrote: > > On Mon, Jan 29, 2024 at 3:14 PM Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote: >> >>> On Jan 29, 2024, at 6:44 AM, Roland Mainz <roland.mainz@xxxxxxxxxxx> wrote: >>> >>> On Mon, Nov 13, 2023 at 2:01 AM Cedric Blancher >>> <cedric.blancher@xxxxxxxxx> wrote: >>>> On Fri, 10 Nov 2023 at 20:17, Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote: >>>>>> On Nov 10, 2023, at 3:30 AM, Martin Wege <martin.l.wege@xxxxxxxxx> wrote: >>>>>> On Fri, Nov 10, 2023 at 3:20 AM Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote: >>>>>>>> On Nov 9, 2023, at 7:47 PM, Cedric Blancher <cedric.blancher@xxxxxxxxx> wrote: >>> [snip] >>>> Yeah, instead of waiting for NetLink you could implement Roland's >>>> suggestion, and change "hostname" to "hostport" in your test-based >>>> mount protocol, and technically everywhere else, like /proc/mounts and >>>> the /sbin/mount output. >>>> So instead of: >>>> mount -t nfs -o port=4444 10.10.0.10:/backups /var/backups >>>> you could use >>>> mount -t nfs 10.10.0.10@4444:/backups /var/backups >>>> >>>> The same applies to refer= - just change from "hostname" to >>>> "hostport", and the text-based mountd downcall can stay the same (e.g. >>>> so "foobarhost" changes to "foobarhost@444" in the mountd download.) >>> [snip] >>> >>> What would be the correct syntax to specify a custom (non-2049) TCP >>> port for refer= in /etc/exports ? >>> >>> Would this work: >>> ---- snip ---- >>> `/ref *(no_root_squash,refer=/export/home@134.49.22.111:32049) >>> ---- snip ---- >> >> Hello Roland - >> >> Although generic NFSv4 referral support has been in NFSD for >> many years, NFSD currently does not implement alternate ports >> in referrals. > > I know, but the question is about the syntax in /etc/exports. The idea > is to use the same syntax for other NFSv4 server implementations (like > nfs4j) ... We're planning not to support alternate ports via the refer= export option. Instead, we plan to add the ability to specify an alternate port via the "nfsref" command. The refer= export option (that is, using this UI for setting up NFSv4 referrals) has been experimental since it was introduced, and has a number of limitations that we hope to avoid by using "nfsref" instead. As an alternative, Solaris, for instance, does not use the /etc/export interface mechanism at all, preferring instead the "share" and "nfsref" commands. (though as far as I am aware, Solaris does not implement support for alternate ports in referrals either). Solaris has support for reparse points (as does FreeBSD). "nfsref" is supposed to be a mechanism for editing those, and theoretically reparse points were supposed to handle more than just NFSv4 referrals. Unfortunately I was never able to generate a lot of appetite in the Linux kernel community for implementing reparse points in our file systems. Our "nfsref" command is therefore somewhat limited. HTH -- Chuck Lever
