hmm this is very interesting.

I am wondering though? Is there something like systemd-nspawn that doesn't require root?

If file system level isolation is enough for you, take a loot at schroot (https://linux.die.net/man/1/schroot) which allows root-less chroot. You can use something like debootstrap to get a complete userland into a user controlled directory and use schroot to chroot into it without root level access.

this is crazy , trying this out right now.

But is there a way to also run OCI compatible directly on this as well?

You could use docker export to sluro the container contents (see article for example)

EDIT: it seems that for creating a chroot you still require root.

I don't have root on that system and so I can't create a chroot , there is fakeroot but it doesn't work since it uses qemu on that locked system.

Are there any other alternatives

fakeroot has nothing to do with qemu -- it simply uses LD preload to make commands think they're uid 0

Fakeroot is good for the debootstrap step, and then schroot runs unprivileged.

> it seems that for creating a chroot you still require root.

You actually don't as long as you have user namespaces.

One thing I am working on I use chroot (rather unshare --root=) to minimally sandbox a subprocess. At the beginning of the script I have this little snippet:

    if [ "$(id --user)" -ne 0 ]; then
     exec unshare --map-root-user --mount -- "$0" "$@"
    fi

Though you can probably just do something roughtly as `unshare --map-root-user --root=<PATH>`.

It looks like systemd-nspawn is gaining rootless support, see https://github.com/systemd/systemd/issues/30239

Until then, I'm not sure if there is anything lightweight. If you don't need lightweight, there is Podman.

Podman requires one time root for installation though.

I am on a completely rootless client at one of my servers.

Nope, you can compile/download and run it completely from unprivileged userspace.

Do note that the current support is limited to signed disk images, while it was recently (still not in a release) gained the ability to use any directory that resides inside a signed disk image (instead of just the entire disk image).

all containers require root.

docker and the rootless nonsense is just root daemons and suid.

...would never have believed marketing lies would reach linux tools if anyone told me this before 2018.

you can theoretically run a virtual machine like libriscv5 which doesn't require root. or qemu doesn't require root as well. But qemu is blocked for my usecase. There is flatpak theoretically as well

There is podman but it requires one time root.

qemu is great but it's a VM, not a container.

Linux user namespaces can be used to create containers without having root access, see ex. https://unix.stackexchange.com/questions/66084/simulate-chro...

There's also https://github.com/termux/proot-distro which may or may not count as containers depending on how you define the word but I think it does count

you can't detach your username from a process, nor the network ns... etc, etc, etc.

yeah you can do some smaller fakechroot and maybe some bind mounts... if you call that a "container" good for you.

> you can't detach your username from a process, nor the network ns... etc, etc, etc.

Sure looks like it works?

  $ unshare -i -n -p -u -T -r -f
  # ls
  # id
  gid=0(root) groups=0(root),65534(nogroup)
  # ip -br a
  lo               DOWN

> yeah you can do some smaller fakechroot and maybe some bind mounts... if you call that a "container" good for you.

Why are you being condescending about what constitutes a container?

I used to use qemu-user-static to run ARM Linux distros like Buildroot, Yocto, and Raspbian on x88_64. It worked surprisingly well! Outside of some minor bugs here and there, it was perfect for local development, emulating an embedded system I was working on.

You might want to look into .nspawn files instead. Then you can also manage your nspawn-containers with the machinectl command.

See man 5 systemd.nspawn

And many command like systemctl and journalctl accept the -M parameter, which allows you to query systemd units inside your nspawn-containers from the host.

edit: The article actually explains all of these things in more detail.

Why run the Debian VM? Just use nspawn directly