From 4dd52cace6fbfee87634cbffa44efe0f191a4192 Mon Sep 17 00:00:00 2001 From: jochen Date: Thu, 8 Oct 2026 21:14:34 +0200 Subject: [PATCH] Design 52: say the workstation's fstab line still mounts at boot until it is adopted, and can hold the boot 30 s --- 03-DESIGN/01-to-be/52-shares-and-mounts.md | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/03-DESIGN/01-to-be/52-shares-and-mounts.md b/03-DESIGN/01-to-be/52-shares-and-mounts.md index b76e7500..08897485 100644 --- a/03-DESIGN/01-to-be/52-shares-and-mounts.md +++ b/03-DESIGN/01-to-be/52-shares-and-mounts.md @@ -185,15 +185,23 @@ folders, none refused for a reason not understood. 2. **Assign `mounts` to the workstation, read-only.** Its `shares` is `library=:ro`. Check `node-mounts.list`: the pair is armed, the share reads `armed` then `mounted` after a listing, and the files are there. Its unit pair takes the place of the unit generated from fstab. + **Until step 5 the hand-written fstab line still acts at boot.** The fstab generator still makes the + mount wanted by `remote-fs.target`, so at every boot the mount is started directly, not on access: + the module's `.mount` (which now carries the line's mount point) is pulled in at boot, can hold the + boot for up to its 30 s mount timeout, and fails when the home server is unreachable. The automount + protects only accesses after that. So step 5 follows soon after the share is seen working, and a + failed mount at boot in this window is expected, not a fault of the module. *Undo:* unassign `mounts`; its unit pairs go, and the fstab line is still there. -3. **Watch for a day.** `mounts_health` and `nfs_health` stay healthy; a reboot of the workstation - completes with the home server's share reachable and with it stopped (the share reads `unreachable` - and the boot does not wait). +3. **Watch for a day.** `mounts_health` and `nfs_health` stay healthy, and a reboot of the workstation + with the home server's share reachable completes and mounts it. A reboot with the share unreachable + still waits up to 30 s and fails the mount while the fstab line stands (step 2); that the boot does + not wait is checked again after step 5. 4. **Read-write.** Change the grant to `rw` and the workstation's setting to drop `:ro`. Write one test file from the workstation, check its owner on the home server is the library's owner, and remove it. *Undo:* set both back to `ro`. 5. **Adopt the workstation's library line**: `node-mounts.adopt` dry run, read it, then with - `confirm` and a reason. *Undo:* the dated copy of fstab beside it. + `confirm` and a reason. From the next boot nothing starts the mount but an access, and a reboot with + the home server stopped completes without waiting. *Undo:* the dated copy of fstab beside it. 6. **Adopt the ZFS property**: `node-nfs-server.adopt` dry run, then confirmed. The home network's export goes; the mesh's stays. *Undo:* `zfs set sharenfs=` by a person, recorded as a hand-act.