What causes "move mount to %s: %w" in dagger/dagger?

Run on a kernel >= 5.2 that supports move_mount(2) and check the engine host kernel version

move mount to %s: %w

Error message

move mount to %s: %w

What it means

mountIntoContainer wraps a failure of the move_mount(2) syscall that attaches the cloned mount tree at targetPath inside the container's mount namespace. Dagger throws it when the kernel rejects attaching the prepared mount FD at the destination. The wrapped errno identifies the specific cause.

Source

Thrown at core/service.go:1605

		{Type: specs.MountNamespace},
	}, func() error {
		// Create target directory if it doesn't exist
		if _, err := os.Stat(targetPath); os.IsNotExist(err) {
			if err := os.MkdirAll(targetPath, 0755); err != nil && !os.IsExist(err) {
				return fmt.Errorf("mkdir %s: %w", targetPath, err)
			}
		}

		// Unmount any existing mount at the target path
		err = unix.Unmount(targetPath, unix.MNT_DETACH)
		if err != nil && err != unix.EINVAL && err != unix.ENOENT {
			slog.Warn("unmount failed during container remount", "path", targetPath, "error", err)
			// Continue anyway, might not be mounted
		}

		err = unix.MoveMount(fdMnt, "", unix.AT_FDCWD, targetPath, unix.MOVE_MOUNT_F_EMPTY_PATH)
		if err != nil {
			return fmt.Errorf("move mount to %s: %w", targetPath, err)
		}

		return nil
	})
}

type ServiceBindings []ServiceBinding

type ServiceBinding struct {
	Service  dagql.ObjectResult[*Service]
	Hostname string
	Aliases  AliasSet
}

// recordBoundServiceFQDNs notes, for each freshly started binding, the fully
// qualified name the running service registered in DNS under, so the executor
// can resolve it directly instead of re-deriving the bare hostname against the
// consuming exec's search domains.

View on GitHub (pinned to 82ba2681db)

Solutions

Run on a kernel >= 5.2 that supports move_mount(2) and check the engine host kernel version
Confirm the engine container/runtime grants mount capabilities (CAP_SYS_ADMIN, allowed syscalls in seccomp profile)
Ensure the target path still exists and is a directory at mount time
Read the wrapped errno (ENOSYS/EINVAL/EPERM) to pinpoint whether it's kernel, capability, or path related

Example fix

// before
// kernel 4.x host: move_mount -> ENOSYS
// after
// upgrade host kernel to >=5.2 or run the engine on a newer node

Defensive patterns

Strategy: try-catch

Try / catch

if errors.Is(err, unix.ENOSYS) || errors.Is(err, syscall.ENOSYS) {
    log.Fatal("move_mount(2) unsupported: kernel >= 5.2 required")
}
if errors.Is(err, unix.EPERM) { log.Printf("mount capability denied: %v", err) }

Prevention

Run the engine on kernels >= 5.2 that implement move_mount(2)
Ensure the container runtime grants mount privileges (no restrictive seccomp dropping move_mount)
Avoid mutating/removing the target path while the mount is in flight

When it happens

Trigger: Running a directory-into-container mount (via the mutable-copy remount path) where move_mount returns an error: invalid target path, cross-filesystem restrictions, missing CAP_SYS_ADMIN in the target namespace, or kernel lacking move_mount support (<5.2).

Common situations: Old kernels without move_mount(2) (returns ENOSYS); target path was removed between mkdir and mount; seccomp/apparmor policy blocking move_mount; userns without mount privileges.

Related errors

AI-assisted analysis of dagger/dagger@82ba2681db (2026-09-05). Data as JSON: /api/errors/429aee7635bb154e. Report an issue: GitHub.