Linux Jails (sandboxes / containers) with Jailmaker

Tried --bind=/dev/sda:/dev/sda, but still not works.

Solution (thanks to @Jip-Hop scrutiny docker container - /dev/sd* · Jip-Hop/jailmaker · Discussion #62 · GitHub)

docker_compatible=1 and --bind-ro=/dev/sda in systemd_nspawn_user_args was the solution.

1 Like

I have problem with jailmaker on freshly installed 24.04 RC1 with root account disabled (recommended option during installation). Documentation on TrueNAS website and github page says Jailmaker installation and operation has to be done with root account, i had to append sudo with every command until ‘jailmaker create’. Sudo doesn’t work, su -c ‘jailmaker create’ doesn’t work. How do i proceed? Do i need to enable root account?

iX says root account will eventually be disabled permanently in future, how will people use Jailmaker when that happen?

It seems to me Jailmaker is rootful containalization, but is it still possible for me to have unprivileged LXC or rootless Podman within privileged LXC?

Can’t you become root with sudo su?

To rule out it has anything to do with the jlmkr alias I recommend you to run ./ create directly from the jailmaker directory. In case you’re not already root, you’d probably have to put sudo in front.

Future is looking bright for Jailmaker


Anyone might know offhand why bridge networking might not be working? I get these errors when I try:

root@dockerrt:/etc/docker# docker container start 7a6d30e48198
Error response from daemon: failed to add interface vethaa2cec3 to sandbox: error setting interface "vethaa2cec3" IP to cannot program address in sandbox interface because it conflicts with existing route {Ifindex: 98 Dst: Src: Gw: <nil> Flags: [] Table: 254 Realm: 0}
Error: failed to start containers: 7a6d30e48198

The conflicting route seems to be because it is being (also) created outside the nspawn-container.

So far I’ve worked around using host networking.

I found docker - Failed to add interface to sandbox - Stack Overflow and docker compose - cannot program address in sandbox interface because it conflicts with existing route - Stack Overflow

From the looks of it it doesn’t seem to be a jailmaker specific issue.

I have found several issues with the latest version of Docker, 26.0.2. Many containers stopped working with networking errors, after upgrading to it.

I have managed to get them working by downgrading Docker to 26.0.1, with the following shell command:

apt-get install docker-ce=5:26.0.1-1~debian.12~bookworm docker-ce-cli=5:26.0.1-1~debian.12~bookworm docker-buildx-plugin docker-compose-plugin

YMMV, but for now this has allowed me to start my containers again.


Considering I just did the cross-grade from ubernerd/nerdctl to jailmkr only today, I might have been bitten in the ass by this then.

The containers that were configured with host networking started fine, while the bridged ones didn’t. I’m gonna try downgrading Docker.

–edit: Yay, it fixed it!


Is anyone available to test/review the upcoming release: Deprecate docker_compatible and gpu_passthrough by Jip-Hop · Pull Request #121 · Jip-Hop/jailmaker · GitHub?

It’s providing more secure defaults for running docker containers and deprecating the docker_compatible config option.

I don’t have a spare machine to test this, but please do not break Tailscale - I have only been able to make it work inside a jail with


If there is a documented, safe alternative, I can test it after-hours - I have a few servers directly accessible via SSH, breaking Tailscale wouldn’t be a big problem on them.

1 Like

It’s supposed to be a non-breaking update. And even after removing the docker_compatible option in the future there’s nothing stopping users from manually configuring equivalent options.

1 Like

I’d be happy to help test with my setup. The only host network configured container I have is Home Assistant.

1 Like

Question… I have a container (systemd_nspawn_user_args=--bind='/mnt/Vortex/Media:/mnt/media' --bind=/dev/fuse). I then mount /mnt/media with rar2fs under /mnt/rar2fs using AutoFS. At this point /mnt/rar2fs works as expected.

Now, is it possible to somehow make the /mnt/rar2fs mount visible in the host? Or is there a different way I can use a container with rar2fs where the output filesystem is visible in the host?


the contents of /mnt/rar2fs inside the jail should be visible in your jailmaker/jails/<jailname>/rootfs/mnt/rar2fs directory

But what do you then want to do from the host with that? That you could’t do from inside the jail instead?

If you wanted to you could probably bind mount that again somewhere else… into the file system.

While I see all the content inside /mnt/rar2fs in the jail, jailmaker/jails/<jailname>/rootfs/mnt/rar2fs on the host is empty.

I want to be able to share trough SMB the rar2fs output that is visible in the jail under /mnt/rar2fs (preferably trough TrueNAS Sharing page)

I’m sorry, I was going to test what I wrote before posting… but got side-tracked.

You’re right, the above doesn’t work.

I don’t think this is possible, even if you were to somehow take the isolation by the jail out of the equation. SMB on SCALE integrates heavily with ZFS (datasets). Your AutoFS mount is not a ZFS dataset so you can’t share it from the TrueNAS GUI. Your best bet is to share (via SMB or otherwise) from inside the jail. Or you’re going to have to extract the rar file or copy the contents of the mount to a dataset which can be shared via SMB.

Is there something special I missed when trying to do so?

TrueNAS is using x.x.x.124 and the rar2fs container x.x.x.125. I’ve installed samba and configured the share like I always do, added a new smb user (smbpasswd -a <username>) but I can’t seem to be able to mount it from any debian VM or access it from Windows… :worried: (I can ping the container from Windows but when trying to access the share I get an instant error message: Windows cannot access \x.x.x.125)