After a reboot, ZFS-backed containers still appear in `enroot list` (the dataset exists) but their mountpoint directory is empty — the rootfs is inaccessible until something explicitly remounts the dataset.
Root cause
Plan A creates user containers and templates with `canmount=noauto` (intentionally — `zfs mount` requires `CAP_SYS_ADMIN` which unprivileged callers don't have; the cap-elevated `enroot-zfs-mount` helper handles the runtime mount). The trade-off: `zfs mount -a` on boot skips datasets with `canmount=noauto`, so nothing remounts them.
Affected datasets:
- `/<container_name>` — user containers (storage_zfs.sh `zfs::clone_container`)
- `/.templates/` — templates (multiple call sites; templates currently get unmounted-when-idle anyway, so on next `create` they get re-mounted by the cap helper)
- `/.layers/` (Plan G) — layer datasets, same shape
Symptoms
```
$ enroot list
my-container <-- shown because the dataset exists in the store
$ enroot start my-container
enroot-switchroot: failed to chdir: /var/lib/enroot/my-container/etc: No such file or directory
$ ls /var/lib/enroot/my-container/
<-- empty; mountpoint dir is bare, dataset is unmounted
```
Possible fixes
- On-demand remount in `runtime::start`. Before pivot, if backend is zfs, call `enroot-zfs-mount ` (idempotent — already-mounted is a silent no-op). Cheapest and most localized.
- Systemd unit / mount-on-boot. A unit that runs `enroot-zfs-mount` on every `/<*>` dataset at boot. Heavier; needs root or a setuid helper invocation.
- Drop `canmount=noauto`. Would make `zfs mount -a` cover us, but breaks the unprivileged-create story (the create-time automount would fail).
(1) is the right scope. `enroot-zfs-mount` already idempotent-checks the mount state; calling it from `runtime::start` adds at most one stat() per start.
Acceptance
- After a reboot, `enroot start ` works without manual remount.
- No regression in the unprivileged-create path (template creation still works without CAP_SYS_ADMIN at creation time).
- Idempotent — repeated starts don't re-mount or warn.
After a reboot, ZFS-backed containers still appear in `enroot list` (the dataset exists) but their mountpoint directory is empty — the rootfs is inaccessible until something explicitly remounts the dataset.
Root cause
Plan A creates user containers and templates with `canmount=noauto` (intentionally — `zfs mount` requires `CAP_SYS_ADMIN` which unprivileged callers don't have; the cap-elevated `enroot-zfs-mount` helper handles the runtime mount). The trade-off: `zfs mount -a` on boot skips datasets with `canmount=noauto`, so nothing remounts them.
Affected datasets:
Symptoms
```
$ enroot list
my-container <-- shown because the dataset exists in the store
$ enroot start my-container
enroot-switchroot: failed to chdir: /var/lib/enroot/my-container/etc: No such file or directory
$ ls /var/lib/enroot/my-container/
<-- empty; mountpoint dir is bare, dataset is unmounted
```
Possible fixes
(1) is the right scope. `enroot-zfs-mount` already idempotent-checks the mount state; calling it from `runtime::start` adds at most one stat() per start.
Acceptance