ZFS: auto-remount containers in start/export paths after reboot by sodre · Pull Request #19 · zeroae/enroot

sodre · 2026-05-02T12:16:14Z

Closes#18.

ZFS clones are created with canmount=noauto (deliberate — zfs mount
needs CAP_SYS_ADMIN, so the cap-elevated enroot-zfs-mount helper
handles runtime mounting on demand). Side-effect: zfs mount -a at boot
skips them, so after a reboot enroot list still names the container
(its dataset is intact) but the mountpoint is empty and enroot start
errors with No such file or directory.

Fix: a small zfs::ensure_container_mounted helper that calls
enroot-zfs-mount on the named dataset. The cap helper is already
idempotent (silent no-op on already-mounted), so the call is safe to
make every time. Wired into runtime::start and runtime::_export_sqsh
before each path-walks the rootfs. Templates already get explicit mount
calls in their lifecycle helpers; user containers and exported sqsh
sources were the gap.

Smoke (spark-ctrl, OpenZFS 2.4.1, 3.75G test pool)

Test	Result
Create alpine, `zfs unmount` to simulate reboot, `enroot start`	✓ auto-remounts, prints `os-release`
Idempotent re-start when already mounted	✓ silent no-op
`enroot start <does-not-exist>`	✓ clean `No such file or directory`
`zfs unmount`, `enroot export -o /tmp/x.sqsh <name>`	✓ auto-remounts, produces valid 8MB squashfs

Out of scope

enroot list showing names of unmounted-but-existing datasets is
pre-existing Plan A behavior. The list command path-walks
ENROOT_DATA_PATH; switching to zfs list -d 1 for the ZFS backend
would be more honest but is a follow-up.
runtime::_remove_zfs works through zfs::destroy_container which
doesn't need a mount, so no fix is needed there.

🤖 Generated with Claude Code

Fix#18: ZFS clones are created with canmount=noauto so unprivileged callers don't trigger CAP_SYS_ADMIN-gated automount at create time, but the same property makes `zfs mount -a` skip them at boot. After a reboot, datasets exist (so `enroot list` still names them) but their mountpoints are empty, and `enroot start` failed with "No such file or directory" until the user ran `zfs mount` by hand. Add a small idempotent zfs::ensure_container_mounted helper that calls enroot-zfs-mount on the named dataset (silent no-op on already-mounted) and invoke it from runtime::start and runtime::_export_sqsh before each function path-walks the rootfs. Templates already get explicit mount calls in their lifecycle helpers; user containers and exported sqsh sources were the gap. Verified on spark-ctrl with a simulated reboot (zfs unmount of a live container's dataset): pre-fix `enroot start` errored, post-fix it remounts and runs. Idempotent on already-mounted datasets, error path on a non-existent name still surfaces a clean "No such file or directory" rather than a zfs internal error. Signed-off-by: Patrick Sodré <patrick@zero-ae.com>

sodre · 2026-05-02T12:16:14Z

Closes#18.

ZFS clones are created with canmount=noauto (deliberate — zfs mount
needs CAP_SYS_ADMIN, so the cap-elevated enroot-zfs-mount helper
handles runtime mounting on demand). Side-effect: zfs mount -a at boot
skips them, so after a reboot enroot list still names the container
(its dataset is intact) but the mountpoint is empty and enroot start
errors with No such file or directory.

Fix: a small zfs::ensure_container_mounted helper that calls
enroot-zfs-mount on the named dataset. The cap helper is already
idempotent (silent no-op on already-mounted), so the call is safe to
make every time. Wired into runtime::start and runtime::_export_sqsh
before each path-walks the rootfs. Templates already get explicit mount
calls in their lifecycle helpers; user containers and exported sqsh
sources were the gap.

Smoke (spark-ctrl, OpenZFS 2.4.1, 3.75G test pool)

Test	Result
Create alpine, `zfs unmount` to simulate reboot, `enroot start`	✓ auto-remounts, prints `os-release`
Idempotent re-start when already mounted	✓ silent no-op
`enroot start <does-not-exist>`	✓ clean `No such file or directory`
`zfs unmount`, `enroot export -o /tmp/x.sqsh <name>`	✓ auto-remounts, produces valid 8MB squashfs

Out of scope

enroot list showing names of unmounted-but-existing datasets is
pre-existing Plan A behavior. The list command path-walks
ENROOT_DATA_PATH; switching to zfs list -d 1 for the ZFS backend
would be more honest but is a follow-up.
runtime::_remove_zfs works through zfs::destroy_container which
doesn't need a mount, so no fix is needed there.

🤖 Generated with Claude Code

Fix#18: ZFS clones are created with canmount=noauto so unprivileged callers don't trigger CAP_SYS_ADMIN-gated automount at create time, but the same property makes `zfs mount -a` skip them at boot. After a reboot, datasets exist (so `enroot list` still names them) but their mountpoints are empty, and `enroot start` failed with "No such file or directory" until the user ran `zfs mount` by hand. Add a small idempotent zfs::ensure_container_mounted helper that calls enroot-zfs-mount on the named dataset (silent no-op on already-mounted) and invoke it from runtime::start and runtime::_export_sqsh before each function path-walks the rootfs. Templates already get explicit mount calls in their lifecycle helpers; user containers and exported sqsh sources were the gap. Verified on spark-ctrl with a simulated reboot (zfs unmount of a live container's dataset): pre-fix `enroot start` errored, post-fix it remounts and runs. Idempotent on already-mounted datasets, error path on a non-existent name still surfaces a clean "No such file or directory" rather than a zfs internal error. Signed-off-by: Patrick Sodré <patrick@zero-ae.com>

sodre · 2026-05-02T12:16:14Z

Closes#18.

ZFS clones are created with canmount=noauto (deliberate — zfs mount
needs CAP_SYS_ADMIN, so the cap-elevated enroot-zfs-mount helper
handles runtime mounting on demand). Side-effect: zfs mount -a at boot
skips them, so after a reboot enroot list still names the container
(its dataset is intact) but the mountpoint is empty and enroot start
errors with No such file or directory.

Fix: a small zfs::ensure_container_mounted helper that calls
enroot-zfs-mount on the named dataset. The cap helper is already
idempotent (silent no-op on already-mounted), so the call is safe to
make every time. Wired into runtime::start and runtime::_export_sqsh
before each path-walks the rootfs. Templates already get explicit mount
calls in their lifecycle helpers; user containers and exported sqsh
sources were the gap.

Smoke (spark-ctrl, OpenZFS 2.4.1, 3.75G test pool)

Test	Result
Create alpine, `zfs unmount` to simulate reboot, `enroot start`	✓ auto-remounts, prints `os-release`
Idempotent re-start when already mounted	✓ silent no-op
`enroot start <does-not-exist>`	✓ clean `No such file or directory`
`zfs unmount`, `enroot export -o /tmp/x.sqsh <name>`	✓ auto-remounts, produces valid 8MB squashfs

Out of scope

enroot list showing names of unmounted-but-existing datasets is
pre-existing Plan A behavior. The list command path-walks
ENROOT_DATA_PATH; switching to zfs list -d 1 for the ZFS backend
would be more honest but is a follow-up.
runtime::_remove_zfs works through zfs::destroy_container which
doesn't need a mount, so no fix is needed there.

🤖 Generated with Claude Code

Fix#18: ZFS clones are created with canmount=noauto so unprivileged callers don't trigger CAP_SYS_ADMIN-gated automount at create time, but the same property makes `zfs mount -a` skip them at boot. After a reboot, datasets exist (so `enroot list` still names them) but their mountpoints are empty, and `enroot start` failed with "No such file or directory" until the user ran `zfs mount` by hand. Add a small idempotent zfs::ensure_container_mounted helper that calls enroot-zfs-mount on the named dataset (silent no-op on already-mounted) and invoke it from runtime::start and runtime::_export_sqsh before each function path-walks the rootfs. Templates already get explicit mount calls in their lifecycle helpers; user containers and exported sqsh sources were the gap. Verified on spark-ctrl with a simulated reboot (zfs unmount of a live container's dataset): pre-fix `enroot start` errored, post-fix it remounts and runs. Idempotent on already-mounted datasets, error path on a non-existent name still surfaces a clean "No such file or directory" rather than a zfs internal error. Signed-off-by: Patrick Sodré <patrick@zero-ae.com>

sodre · 2026-05-02T12:16:14Z

Closes#18.

ZFS clones are created with canmount=noauto (deliberate — zfs mount
needs CAP_SYS_ADMIN, so the cap-elevated enroot-zfs-mount helper
handles runtime mounting on demand). Side-effect: zfs mount -a at boot
skips them, so after a reboot enroot list still names the container
(its dataset is intact) but the mountpoint is empty and enroot start
errors with No such file or directory.

Fix: a small zfs::ensure_container_mounted helper that calls
enroot-zfs-mount on the named dataset. The cap helper is already
idempotent (silent no-op on already-mounted), so the call is safe to
make every time. Wired into runtime::start and runtime::_export_sqsh
before each path-walks the rootfs. Templates already get explicit mount
calls in their lifecycle helpers; user containers and exported sqsh
sources were the gap.

Smoke (spark-ctrl, OpenZFS 2.4.1, 3.75G test pool)

Test	Result
Create alpine, `zfs unmount` to simulate reboot, `enroot start`	✓ auto-remounts, prints `os-release`
Idempotent re-start when already mounted	✓ silent no-op
`enroot start <does-not-exist>`	✓ clean `No such file or directory`
`zfs unmount`, `enroot export -o /tmp/x.sqsh <name>`	✓ auto-remounts, produces valid 8MB squashfs

Out of scope

enroot list showing names of unmounted-but-existing datasets is
pre-existing Plan A behavior. The list command path-walks
ENROOT_DATA_PATH; switching to zfs list -d 1 for the ZFS backend
would be more honest but is a follow-up.
runtime::_remove_zfs works through zfs::destroy_container which
doesn't need a mount, so no fix is needed there.

🤖 Generated with Claude Code

Fix#18: ZFS clones are created with canmount=noauto so unprivileged callers don't trigger CAP_SYS_ADMIN-gated automount at create time, but the same property makes `zfs mount -a` skip them at boot. After a reboot, datasets exist (so `enroot list` still names them) but their mountpoints are empty, and `enroot start` failed with "No such file or directory" until the user ran `zfs mount` by hand. Add a small idempotent zfs::ensure_container_mounted helper that calls enroot-zfs-mount on the named dataset (silent no-op on already-mounted) and invoke it from runtime::start and runtime::_export_sqsh before each function path-walks the rootfs. Templates already get explicit mount calls in their lifecycle helpers; user containers and exported sqsh sources were the gap. Verified on spark-ctrl with a simulated reboot (zfs unmount of a live container's dataset): pre-fix `enroot start` errored, post-fix it remounts and runs. Idempotent on already-mounted datasets, error path on a non-existent name still surfaces a clean "No such file or directory" rather than a zfs internal error. Signed-off-by: Patrick Sodré <patrick@zero-ae.com>

sodre · 2026-05-02T12:16:14Z

Closes#18.

ZFS clones are created with canmount=noauto (deliberate — zfs mount
needs CAP_SYS_ADMIN, so the cap-elevated enroot-zfs-mount helper
handles runtime mounting on demand). Side-effect: zfs mount -a at boot
skips them, so after a reboot enroot list still names the container
(its dataset is intact) but the mountpoint is empty and enroot start
errors with No such file or directory.

Fix: a small zfs::ensure_container_mounted helper that calls
enroot-zfs-mount on the named dataset. The cap helper is already
idempotent (silent no-op on already-mounted), so the call is safe to
make every time. Wired into runtime::start and runtime::_export_sqsh
before each path-walks the rootfs. Templates already get explicit mount
calls in their lifecycle helpers; user containers and exported sqsh
sources were the gap.

Smoke (spark-ctrl, OpenZFS 2.4.1, 3.75G test pool)

Test	Result
Create alpine, `zfs unmount` to simulate reboot, `enroot start`	✓ auto-remounts, prints `os-release`
Idempotent re-start when already mounted	✓ silent no-op
`enroot start <does-not-exist>`	✓ clean `No such file or directory`
`zfs unmount`, `enroot export -o /tmp/x.sqsh <name>`	✓ auto-remounts, produces valid 8MB squashfs

Out of scope

enroot list showing names of unmounted-but-existing datasets is
pre-existing Plan A behavior. The list command path-walks
ENROOT_DATA_PATH; switching to zfs list -d 1 for the ZFS backend
would be more honest but is a follow-up.
runtime::_remove_zfs works through zfs::destroy_container which
doesn't need a mount, so no fix is needed there.

🤖 Generated with Claude Code

Fix#18: ZFS clones are created with canmount=noauto so unprivileged callers don't trigger CAP_SYS_ADMIN-gated automount at create time, but the same property makes `zfs mount -a` skip them at boot. After a reboot, datasets exist (so `enroot list` still names them) but their mountpoints are empty, and `enroot start` failed with "No such file or directory" until the user ran `zfs mount` by hand. Add a small idempotent zfs::ensure_container_mounted helper that calls enroot-zfs-mount on the named dataset (silent no-op on already-mounted) and invoke it from runtime::start and runtime::_export_sqsh before each function path-walks the rootfs. Templates already get explicit mount calls in their lifecycle helpers; user containers and exported sqsh sources were the gap. Verified on spark-ctrl with a simulated reboot (zfs unmount of a live container's dataset): pre-fix `enroot start` errored, post-fix it remounts and runs. Idempotent on already-mounted datasets, error path on a non-existent name still surfaces a clean "No such file or directory" rather than a zfs internal error. Signed-off-by: Patrick Sodré <patrick@zero-ae.com>

sodre · 2026-05-02T12:16:14Z

Closes#18.

ZFS clones are created with canmount=noauto (deliberate — zfs mount
needs CAP_SYS_ADMIN, so the cap-elevated enroot-zfs-mount helper
handles runtime mounting on demand). Side-effect: zfs mount -a at boot
skips them, so after a reboot enroot list still names the container
(its dataset is intact) but the mountpoint is empty and enroot start
errors with No such file or directory.

Fix: a small zfs::ensure_container_mounted helper that calls
enroot-zfs-mount on the named dataset. The cap helper is already
idempotent (silent no-op on already-mounted), so the call is safe to
make every time. Wired into runtime::start and runtime::_export_sqsh
before each path-walks the rootfs. Templates already get explicit mount
calls in their lifecycle helpers; user containers and exported sqsh
sources were the gap.

Smoke (spark-ctrl, OpenZFS 2.4.1, 3.75G test pool)

Test	Result
Create alpine, `zfs unmount` to simulate reboot, `enroot start`	✓ auto-remounts, prints `os-release`
Idempotent re-start when already mounted	✓ silent no-op
`enroot start <does-not-exist>`	✓ clean `No such file or directory`
`zfs unmount`, `enroot export -o /tmp/x.sqsh <name>`	✓ auto-remounts, produces valid 8MB squashfs

Out of scope

enroot list showing names of unmounted-but-existing datasets is
pre-existing Plan A behavior. The list command path-walks
ENROOT_DATA_PATH; switching to zfs list -d 1 for the ZFS backend
would be more honest but is a follow-up.
runtime::_remove_zfs works through zfs::destroy_container which
doesn't need a mount, so no fix is needed there.

🤖 Generated with Claude Code

Fix#18: ZFS clones are created with canmount=noauto so unprivileged callers don't trigger CAP_SYS_ADMIN-gated automount at create time, but the same property makes `zfs mount -a` skip them at boot. After a reboot, datasets exist (so `enroot list` still names them) but their mountpoints are empty, and `enroot start` failed with "No such file or directory" until the user ran `zfs mount` by hand. Add a small idempotent zfs::ensure_container_mounted helper that calls enroot-zfs-mount on the named dataset (silent no-op on already-mounted) and invoke it from runtime::start and runtime::_export_sqsh before each function path-walks the rootfs. Templates already get explicit mount calls in their lifecycle helpers; user containers and exported sqsh sources were the gap. Verified on spark-ctrl with a simulated reboot (zfs unmount of a live container's dataset): pre-fix `enroot start` errored, post-fix it remounts and runs. Idempotent on already-mounted datasets, error path on a non-existent name still surfaces a clean "No such file or directory" rather than a zfs internal error. Signed-off-by: Patrick Sodré <patrick@zero-ae.com>

sodre · 2026-05-02T12:16:14Z

Closes#18.

ZFS clones are created with canmount=noauto (deliberate — zfs mount
needs CAP_SYS_ADMIN, so the cap-elevated enroot-zfs-mount helper
handles runtime mounting on demand). Side-effect: zfs mount -a at boot
skips them, so after a reboot enroot list still names the container
(its dataset is intact) but the mountpoint is empty and enroot start
errors with No such file or directory.

Fix: a small zfs::ensure_container_mounted helper that calls
enroot-zfs-mount on the named dataset. The cap helper is already
idempotent (silent no-op on already-mounted), so the call is safe to
make every time. Wired into runtime::start and runtime::_export_sqsh
before each path-walks the rootfs. Templates already get explicit mount
calls in their lifecycle helpers; user containers and exported sqsh
sources were the gap.

Smoke (spark-ctrl, OpenZFS 2.4.1, 3.75G test pool)

Test	Result
Create alpine, `zfs unmount` to simulate reboot, `enroot start`	✓ auto-remounts, prints `os-release`
Idempotent re-start when already mounted	✓ silent no-op
`enroot start <does-not-exist>`	✓ clean `No such file or directory`
`zfs unmount`, `enroot export -o /tmp/x.sqsh <name>`	✓ auto-remounts, produces valid 8MB squashfs

Out of scope

enroot list showing names of unmounted-but-existing datasets is
pre-existing Plan A behavior. The list command path-walks
ENROOT_DATA_PATH; switching to zfs list -d 1 for the ZFS backend
would be more honest but is a follow-up.
runtime::_remove_zfs works through zfs::destroy_container which
doesn't need a mount, so no fix is needed there.

🤖 Generated with Claude Code

Fix#18: ZFS clones are created with canmount=noauto so unprivileged callers don't trigger CAP_SYS_ADMIN-gated automount at create time, but the same property makes `zfs mount -a` skip them at boot. After a reboot, datasets exist (so `enroot list` still names them) but their mountpoints are empty, and `enroot start` failed with "No such file or directory" until the user ran `zfs mount` by hand. Add a small idempotent zfs::ensure_container_mounted helper that calls enroot-zfs-mount on the named dataset (silent no-op on already-mounted) and invoke it from runtime::start and runtime::_export_sqsh before each function path-walks the rootfs. Templates already get explicit mount calls in their lifecycle helpers; user containers and exported sqsh sources were the gap. Verified on spark-ctrl with a simulated reboot (zfs unmount of a live container's dataset): pre-fix `enroot start` errored, post-fix it remounts and runs. Idempotent on already-mounted datasets, error path on a non-existent name still surfaces a clean "No such file or directory" rather than a zfs internal error. Signed-off-by: Patrick Sodré <patrick@zero-ae.com>

sodre · 2026-05-02T12:16:14Z

Closes#18.

ZFS clones are created with canmount=noauto (deliberate — zfs mount
needs CAP_SYS_ADMIN, so the cap-elevated enroot-zfs-mount helper
handles runtime mounting on demand). Side-effect: zfs mount -a at boot
skips them, so after a reboot enroot list still names the container
(its dataset is intact) but the mountpoint is empty and enroot start
errors with No such file or directory.

Fix: a small zfs::ensure_container_mounted helper that calls
enroot-zfs-mount on the named dataset. The cap helper is already
idempotent (silent no-op on already-mounted), so the call is safe to
make every time. Wired into runtime::start and runtime::_export_sqsh
before each path-walks the rootfs. Templates already get explicit mount
calls in their lifecycle helpers; user containers and exported sqsh
sources were the gap.

Smoke (spark-ctrl, OpenZFS 2.4.1, 3.75G test pool)

Test	Result
Create alpine, `zfs unmount` to simulate reboot, `enroot start`	✓ auto-remounts, prints `os-release`
Idempotent re-start when already mounted	✓ silent no-op
`enroot start <does-not-exist>`	✓ clean `No such file or directory`
`zfs unmount`, `enroot export -o /tmp/x.sqsh <name>`	✓ auto-remounts, produces valid 8MB squashfs

Out of scope

enroot list showing names of unmounted-but-existing datasets is
pre-existing Plan A behavior. The list command path-walks
ENROOT_DATA_PATH; switching to zfs list -d 1 for the ZFS backend
would be more honest but is a follow-up.
runtime::_remove_zfs works through zfs::destroy_container which
doesn't need a mount, so no fix is needed there.

🤖 Generated with Claude Code

Fix#18: ZFS clones are created with canmount=noauto so unprivileged callers don't trigger CAP_SYS_ADMIN-gated automount at create time, but the same property makes `zfs mount -a` skip them at boot. After a reboot, datasets exist (so `enroot list` still names them) but their mountpoints are empty, and `enroot start` failed with "No such file or directory" until the user ran `zfs mount` by hand. Add a small idempotent zfs::ensure_container_mounted helper that calls enroot-zfs-mount on the named dataset (silent no-op on already-mounted) and invoke it from runtime::start and runtime::_export_sqsh before each function path-walks the rootfs. Templates already get explicit mount calls in their lifecycle helpers; user containers and exported sqsh sources were the gap. Verified on spark-ctrl with a simulated reboot (zfs unmount of a live container's dataset): pre-fix `enroot start` errored, post-fix it remounts and runs. Idempotent on already-mounted datasets, error path on a non-existent name still surfaces a clean "No such file or directory" rather than a zfs internal error. Signed-off-by: Patrick Sodré <patrick@zero-ae.com>

sodre merged commit 97617e3 into zenroot/mainMay 2, 2026