On 25 Nov 2024, at 12:21, Mark Liam Brown wrote: > On Mon, Sep 30, 2024 at 4:58 PM Mark Liam Brown <brownmarkliam@xxxxxxxxx> wrote: >> >> On Tue, Sep 3, 2024 at 1:16 PM Mark Liam Brown <brownmarkliam@xxxxxxxxx> wrote: >>> >>> Greetings! >>> >>> How can I add IPV6 localhost to /etc/export, to access a nfs4 share >>> via ssh? I tried, but in wireshark I get this error: >>> 1 0.000000000 ::1 → ::1 NFS 278 V4 Call lookup >>> LOOKUP test14 >>> 2 0.000076041 ::1 → ::1 NFS 214 V4 Reply (Call In >>> 1) lookup PUTROOTFH | GETATTR Status: NFS4ERR_PERM >>> >>> for this entry in /etc/exports: >>> /test14 ::1/64(rw,async,insecure,no_subtree_check,no_root_squash) >>> >>> The same mount attempt works if I replace the entry in /etc/exports with this: >>> /test14 *(rw,async,insecure,no_subtree_check,no_root_squash) >> >> So far "::1/128", "::1/64", "::1" do not work, which makes me wonder >> if there is a BUG in nfsd which prevents the use of ::1 at all. >> >> Also, our IT department made it clear that the "total >> underdocumenation" of IPv6 in exports(5) is "literally worth a CVE", >> as many people use IPv6 masks which make exports world-wide >> accessible. > > So is this a bug, or not? Hi Mark - this does look like a bug, probably in rpc.mountd somewhere, but I can't reproduce it on my system with upstream nfs-utils. Can you turn up the debugging on rpc.mountd and see what's emitted? I think your options might be to convince someone here to dig into it, or file a bug report with your distro, or with upstream nfs-utils (if you can verify this continues to be a problem with the most recent version of nfs-utils). Ben
