2 Commits

Include renames

Author	SHA1	Message	Date
Chris Lu	d265274e13	fix(nfs): accept dirpath any-where under the export, mirroring rclone (#9291) ... * fix(nfs): accept any MOUNT3 dirpath, mirroring rclone's permissive policy weed nfs has exactly one export per process, so the MOUNT3 dirpath argument has no second export to disambiguate against. Strict comparison only translated PV-path typos into the inconsistent "mount succeeds but empty" / "mount fails completely" split that operators see. Match rclone's serve nfs Handler.Mount: ignore the dirpath, log an INFO line when it differs from the configured export, and always serve the export root. Apply the same change to the UDP MOUNT3 path so kernel clients defaulting to mountproto=udp see identical behaviour. Access control still goes through -allowedClients / -ip.bind, and file-handle scoping in FromHandle is unchanged so handles still cannot escape the export. Replace the prior single-path reject tests with table tests covering the shapes operators commonly hit: root, parent, sibling, deeper child, unrelated, empty, relative form, exact match, and trailing slash, at the Handler.Mount, UDP MOUNT3, and full RPC layers. * feat(nfs): mount at subdirectory when MOUNT3 dirpath is under the export Make the dirpath argument meaningful when the client asks for a subtree of the configured export. With -filer.path=/buckets, a client mounting <server>:/buckets/data lands directly inside /buckets/data instead of at the export root. - dirpath equals the export root: serve the export root. - dirpath strictly under the export, directory entry: serve that subdirectory; the returned filehandle encodes its inode. - dirpath strictly under the export, missing or non-directory: reject with NoEnt or NotDir. - dirpath outside the export: keep the rclone-style fallback to the export root. TCP returns a sub-rooted seaweedFileSystem and lets go-nfs's onMount call ToHandle to encode the FH; UDP encodes the FH itself. FromHandle is unchanged: handles are content-addressed by inode and resolve via the inode index, so they remain stable across mounts and across process restarts. The trimmed permissive tests keep their outside-export shapes; new subexport tests cover under-export directories, missing entries, and non-directory entries on Handler.Mount, the UDP MOUNT3 wire, and through the full RPC stack. * nfs: propagate request context through MOUNT3 resolution Mount now accepts the gonfs context and threads it through resolveMountFilesystem and lstatExportStatus so a slow filer call during MOUNT cannot outlive a cancelled or timed-out request. lstatExportStatus uses fileInfoForVirtualPath(ctx, "/") directly instead of billy.Filesystem.Lstat, which would otherwise drop the context on the floor by calling fileInfoForVirtualPathWithOptions with context.Background(). Lower the successful subexport-mount log from V(0) to V(1). The fallback log stays at V(0) so operator typos still surface; the success line is per-mount churn that adds up on NFS-CSI deployments. * nfs: mirror TCP defensive checks on the UDP MOUNT3 path Two transport-parity bugs the rabbit caught: (1) The exact-export-root and outside-export branches were returning MNT3_OK unconditionally, while the TCP handler runs lstatExportStatus on those same branches. If the configured -filer.path has been removed from the filer, TCP returns NoEnt/ServerFault but UDP would still hand out a synthetic root handle pointing at nothing. Add rootMountStatus as the UDP analogue and call it on both branches. (2) resolveSubexportFileHandle did filer I/O on the single UDP serve loop with context.Background(). One slow filer round-trip would block every later MOUNT packet. Wrap each MOUNT call's filer work in context.WithTimeout(mountUDPLookupTimeout) and thread that ctx through both rootMountStatus and resolveSubexportFileHandle. Lower the successful subexport log to V(1) to match the TCP side. * nfs: assert TCP/UDP MOUNT3 produce byte-identical filehandles The existing UDP subexport assertions only checked the decoded inode and kind. A regression that drifted the generation, exportID, or encoding format on one transport but not the other would have slipped through. Build the TCP Handler from the same Server, drive its Mount with the same dirpath, and require ToHandle to match the raw UDP FH bytes for every OK case. * nfs: take MOUNT3 dirpath as string in resolveMountFilesystem Convert req.Dirpath to string once at the call site instead of sprinkling string(...) casts through every log line and conversion inside the function. Behavior unchanged. * nfs: share rootFS lifecycle between TCP and UDP MOUNT handlers Server.rootFilesystem() lazily constructs the seaweedFileSystem rooted at the configured export the first time anything asks for it, then hands the same instance to every subsequent caller. newHandler() and mountUDPServer.rootMountStatus() now both go through it, so: - Both transports observe the same chunk reader cache and chunk invalidator without depending on call order during startup. - The UDP defensive Lstat doesn't allocate a fresh wrapper per MOUNT request anymore; one struct lives for the life of the Server. The sub-rooted seaweedFileSystem the subexport branch builds in resolveSubexportFileHandle is still per-request because actualRoot varies with the requested dirpath. * nfs: drive rootFilesystem before reading sharedReaderCache on UDP The UDP listener is started before serve() calls newHandler(), so an under-export MOUNT3 request can reach resolveSubexportFileHandle before Server.sharedReaderCache has been assigned. Reading it directly would hand newSeaweedFileSystem a nil cache and the sub-fs would build a throwaway ReaderCache that never gets shared with the TCP path. Take rootFS off Server.rootFilesystem() (which drives the sync.Once that initializes the shared cache) and read readerCache off that instead, so subexport sub-fs instances always share the same reader cache as rootFS regardless of which transport sees the first MOUNT. * nfs: collapse exact-match and outside-export MOUNT branches The two branches return the same filesystem (export root) and the same status; only the log line differs. Combine the conditions and guard the fallback log inline. Behavior unchanged.	2026-04-30 10:06:44 -07:00
Chris Lu	35fe3c801b	feat(nfs): UDP MOUNT v3 responder + real-Linux e2e mount harness (#9267) ... * feat(nfs): add UDP MOUNT v3 responder The upstream willscott/go-nfs library only serves the MOUNT protocol over TCP. Linux's mount.nfs and the in-kernel NFS client default mountproto to UDP in many configurations, so against a stock weed nfs deployment the kernel queries portmap for "MOUNT v3 UDP", gets port=0 ("not registered"), and either falls back inconsistently or surfaces EPROTONOSUPPORT — surfacing as the user-visible "requested NFS version or transport protocol is not supported" reported in #9263. The user has to add `mountproto=tcp` or `mountport=2049` to mount options to coerce TCP just for the MOUNT phase. Add a small UDP responder that speaks just enough of MOUNT v3 to handle the procedures the kernel actually invokes during mount setup and teardown: NULL, MNT, and UMNT. The wire layout for MNT mirrors handler.go's TCP path so both transports produce the same root filehandle and the same auth flavor list for the same export. Other v3 procedures (DUMP, EXPORT, UMNTALL) cleanly return PROC_UNAVAIL. This commit only adds the responder; portmap-advertise and Server.Start wire-up follow in subsequent commits so each step stays independently reviewable. References: RFC 1813 §5 (NFSv3/MOUNTv3), RFC 5531 (RPC). Existing constants and parseRPCCall / encodeAcceptedReply helpers from portmap.go are reused so behaviour stays consistent across both UDP listening goroutines. * feat(nfs): advertise UDP MOUNT v3 in the portmap responder The portmap responder advertised TCP-only entries because go-nfs only serves TCP, but with the new UDP MOUNT responder in place we can now honestly advertise MOUNT v3 over UDP as well. Linux clients whose default mountproto is UDP query portmap during mount setup; if the answer is "not registered" some kernels translate the result to EPROTONOSUPPORT instead of falling back to TCP, which is exactly the failure pattern reported in #9263. Add the entry, refresh the doc comment, and extend the existing GETPORT and DUMP unit tests so a regression that drops the entry shows up at unit-test granularity rather than only in an end-to-end mount. * feat(nfs): start UDP MOUNT v3 responder alongside the TCP NFS listener Plug the new mountUDPServer into Server.Start so it comes up on the same bind/port as the TCP NFS listener. Started before portmap so a portmap query that races a fast client never returns a UDP MOUNT entry the responder isn't actually answering, and shut down via the same defer chain so a portmap-or-listener startup failure doesn't leave the UDP responder dangling. The portmap startup log now reflects all three advertised entries (NFS v3 tcp, MOUNT v3 tcp, MOUNT v3 udp) so operators can confirm at a glance that the UDP MOUNT path is up. Verified end-to-end: built a Linux/arm64 binary, ran weed nfs in a container with -portmap.bind, and mounted from another container using both the user-reported failing setup from #9263 (vers=3 + tcp without mountport) and an explicit mountproto=udp to force the new code path. The trace `mount.nfs: trying ... prog 100005 vers 3 prot UDP port 2049` now leads to a successful mount instead of EPROTONOSUPPORT. * docs(nfs): note that the plain mount form works on UDP-default clients With UDP MOUNT v3 now served alongside TCP, the only path that ever required mountproto=tcp / mountport=2049 — clients whose default mountproto is UDP — works against the plain mount example. Update the startup mount hint and the `weed nfs` long help so users don't go hunting for a mount-option workaround that no longer applies. The "without -portmap.bind" branch is unchanged: that path still has to bypass portmap entirely because there is no portmap responder for the kernel to query. * test(nfs): add kernel-mount e2e tests under test/nfs The existing test/nfs/ harness boots a real master + volume + filer + weed nfs subprocess stack and drives it via go-nfs-client. That covers protocol behaviour from a Go client's perspective, but anything mis-coded once a real Linux kernel parses the wire bytes is invisible: both ends of the test use the same RPC library, so identical bugs round-trip cleanly. The two NFS issues hit recently were exactly that shape — NFSv4 mis-routed to v3 SETATTR (#9262) and missing UDP MOUNT v3 — and only surfaced in a real client. Add three end-to-end tests that mount the harness's running NFS server through the in-tree Linux client: - TestKernelMountV3TCP: NFSv3 + MOUNT v3 over TCP (baseline). - TestKernelMountV3MountProtoUDP: NFSv3 over TCP, MOUNT v3 over UDP only — regression test for the new UDP MOUNT v3 responder. - TestKernelMountV4RejectsCleanly: vers=4 against the v3-only server, asserting the kernel surfaces a protocol/version-level error rather than a generic "mount system call failed" — regression test for the PROG_MISMATCH path from #9262. The tests pass explicit port=/mountport= mount options so the kernel never queries portmap, which means the harness doesn't need to bind the privileged port 111 and won't collide with a system rpcbind on a shared CI runner. They t.Skip cleanly when the host isn't Linux, when mount.nfs isn't installed, or when the test process isn't running as root. Run locally with: cd test/nfs sudo go test -v -run TestKernelMount ./... CI wiring follows in the next commit. * ci(nfs): run kernel-mount e2e tests in nfs-tests workflow Wire the new TestKernelMount* tests from test/nfs into the existing NFS workflow: - Existing protocol-layer step now skips '^TestKernelMount' so a "skipped because not root" line doesn't appear on every run. - New "Install kernel NFS client" step pulls nfs-common (mount.nfs + helpers) and netbase (/etc/protocols, which mount.nfs's protocol- name lookups need to resolve `tcp`/`udp`). - New privileged step runs only the kernel-mount tests under sudo, preserving PATH and pointing GOMODCACHE/GOCACHE at the user's caches so the second `go test` invocation reuses already-built test binaries instead of redownloading modules under root. The summary block now lists the three kernel-mount cases explicitly so a regression on either of #9262 or this PR's UDP MOUNT change is traceable from the workflow run page.	2026-04-28 14:06:35 -07:00