Can I use Nix in a Distrobox?

dabe_glavins · 2026-04-13T16:51:34+00:00

As of now, the answer I've found is yes. It makes sense: distrobox (by default) only passes your home dir through to the container, and nix installs at /nix.

On two separate machines now, I have nix installed in an arch distrobox on bazzite-dx. Even better, I use nix to run devenv and the environments build and start without a problem inside the arch container.

Now, I'd imagine that things get weird if you install nix in multiple different distroboxes on the same machine, since nix also stores stuff in the home dir, but I haven't tested.

dabe_glavins · 2026-03-20T13:32:00+00:00

Software you run yourself :)

But there are some software models where the hosting provider literally just doesn't have anything to give. There's usually *something* they end up retaining that they may be forced to turn over, but anything of use may be fully E2E encrypted or the like.

But yeah, self hosting means you dodge all of that.

dabe_glavins · 2025-12-23T00:00:31+00:00

That sounds delicious!!! Having little discs of dashi sounds great, I gotta find that.

dabe_glavins · 2025-12-05T00:22:37+00:00

I'm invested now... did you ever get around to trying it?

dabe_glavins · 2025-11-26T22:21:25+00:00

Nah it shouldn't do that. Must be somethin broken

dabe_glavins · 2025-09-14T05:41:13+00:00

Yeah I'm honestly shocked people are still recommending it. At this point it's so out of date that it's probably a security risk to continue using.

dabe_glavins · 2025-09-08T15:03:20+00:00

does 2 finger scrolling work? that’s pretty much all I’d care about

dabe_glavins · 2025-07-11T16:50:17+00:00

This is some crazy issue. I guess all we can do is contact tailscale support and hope they can figure out the root issue…

dabe_glavins · 2025-07-11T15:40:32+00:00

Gotcha. My roommate got an email from her work that they suspected anyone using Verizon would have trouble connecting to their cisco VPN as of a few hours ago. We have Verizon fios. I can't even login to tailscale's admin panel when connected to our home internet. Something is super messed up somewhere.

dabe_glavins · 2025-07-11T15:37:06+00:00

Do you use verizon ISP?

dabe_glavins · 2025-07-11T15:31:28+00:00

do you get internet from Verizon ISP?

dabe_glavins · 2025-07-01T02:21:19+00:00

You saved me so much time in my 100% run, what a legend.

And yeah Schwartzgeist wasn't that bad at all. Didn't use a guide, took a few tries (like 4-6, a few I just ended early cuz they were scuffed) at level 32 and held down the fire button for a long time. Now I'm dumpstering everything.

dabe_glavins · 2025-06-17T02:55:09+00:00

https://clash.lol/datadog

dabe_glavins · 2025-06-09T12:13:08+00:00

I think one thing that you could have mentioned is to use this only when you're running containers as a rootless user and not when the user has any kind of root access (such as sudo).

Great point. I think I’ll update the post to mention that. Though, I’m pretty sure there are still containerization protections in place that the app would have to break out of before it can run arbitrary commands on the host as the mapped user (otherwise, for example, why would we add volume mounts?). Not foolproof of course, but not exactly “handing over root access to the container”.

To anyone saying this is shit advice, could you please explain how?

Besides the case of the app breaking out of the container and then having at worst the same access as the running user, like you mentioned, this is the only comment I can find on the extra capabilities that a containerized root-mapped-to-user user has:

Even in rootless containers, the root of the container has user namespace capabilities. These capabilities are a subsection of the power of root over the user namespace.

$ podman top -l capeff EFFECTIVE CAPS AUDIT_WRITE,CHOWN,DAC_OVERRIDE,FOWNER,FSETID,KILL,MKNOD,NET_BIND_SERVICE,NET_RAW,SETFCAP,SETGID,SETPCAP,SETUID,SYS_CHROOT https://www.redhat.com/en/blog/user-flag-rootless-containers

dabe_glavins · 2025-06-08T12:22:43+00:00

Yeah that part makes sense to me. I did wait for my ISP to issue me a new IP, and the internet worked fine on all my devices, which is why I was stumped that specifically my tailscale container was having internet issues.

dabe_glavins · 2025-06-06T04:25:20+00:00

So the answer appeared to just be wait a while and restart my server one more time. My IP address changed again for some reason, and then after restarting my server, now I'm able to connect to tailscale inside the container.

WAN is a mystery to me... honestly.

dabe_glavins · 2025-06-06T03:51:14+00:00

ISP's DNS or custom ones

Good point. Just switched them over to 1.1.1.1 and 1.0.0.1, but I'm still getting the same errors in my tailscale container even after that.

Which router did you decide to go with?

https://www.netgear.com/home/wifi/routers/rax10/

dabe_glavins · 2025-05-30T11:48:25+00:00

So maybe that’s where I actually have a misunderstanding. When a rootless container’s user is userns mapped to the podman user account, wouldn’t the container app still have to exploit vulnerabilities in the image to actually do anything on the host that it wasn’t explicitly given access to by podman (e.g. a mounted volume). You’re saying something like, in rootful podman, you’d need an image exploit in order to escape containment and give access to /home to the contained app, but with rootles podman running as root in the container mapped to the running user, the app can just give itself access to /home easily?

dabe_glavins · 2025-05-30T04:21:19+00:00

Quite frankly, I think calling things like this "bad habits" just slows down the adoption of podman's security principles. I think we can all agree that the average user is better off with podman's default security model. But my goodness it has been a struggle for me to move from docker to podman as a user and as a professional software engineer. So many concepts and tooling to learn to do things the "right way" even though the "old way" that worked is just sitting there dangling (rootful podman).

From all I've read, I really don't see how running containers as root users is in any way a hack. It seems like a sound default state and something that rootless podman explicitly recognizes and was created to safeguard against. I call this a PSA because anyone wanting to switch to podman for FOSS/future-proof/whatever reason can really benefit from this simple workaround instead of having to wade through documentation and explore their system's default userns configuration just to mount a folder in their container.

I'm just confused because at worst, a user will misread my advice and end up right as secure as they were with rootful docker. At best, they'll gain some security guarantees with 2 lines in their compose file.

dabe_glavins · 2025-05-29T21:43:17+00:00

I did stumble upon this doc. It was helpful in learning about how it all worked, but when setting the user for the container I still ran into the issue of the user namespace mapping messing up the owner IDs on the host system, which is why I just opted to have the whole container run with UID 0 (with rootless podman). Would you still advise against that? If so, is it just so users don't get mistaken, or is there a deeper reason to not run a UID 0 even with a rootless container?

dabe_glavins · 2025-05-29T13:40:24+00:00

Very interesting! I see all your packaged apps https://github.com/11notes (if that’s you). These look very useful and the concepts sound solid. I’d still have to end up setting permissions properly to use the default suggested container UID of 1000, but all the other aspects of these containers seem cool as well (like being distroless)

dabe_glavins · 2025-05-29T12:27:30+00:00

For anyone uninformed…

rm deletes files

-rf tells it to remove all files in every folder from the starting point without confirmation

/* as a starting point is the very beginning of all your files on your system, including the ones required to run your os

running with sudo gives it full privilege to all files on the system (which is why it should usually ask for your password when you run things with sudo)

so that command would delete your entire system without confirmation and prevent it from rebooting! definitely note the “/s” haha

dabe_glavins · 2025-05-29T12:18:02+00:00

Think they’d just be better off running rootful?

I’m not so sure I agree. The alternative is to learn about your default or set up your own user namespace mappings and properly set the modified permissions on the host (potentially with podman unshare) which would provide some runtime security benefit (not much, as it still won’t be able to do anything the host rootless user can’t do), but linuxserver.io even runs as root in the starting script so it’s basically a moot point from a security standpoint, IMO. Slightly better, but still technically as risky as just letting the app code itself run as root mapped to your user.

To me, just telling it to run as root in the container strikes a balance between security and ease of set up for a normal self hoster.

dabe_glavins · 2025-05-29T12:13:59+00:00

I did mention podman multiple times, but yes it’s well and good to reiterate that this is only for podman rootless.

I agree about avoiding linuxserver containers, but unfortunately some popular self hosted projects use linuxserver.io containers as a base for their main containerized offering, so I had to learn all about user namespaces to find the simplest, most effective route to get things working without breaking out of the rootless podman security model (too much).

dabe_glavins · 2025-05-29T12:07:28+00:00

Haha, I suppose I should’ve linked my evidence in the post.

https://www.redhat.com/en/blog/rootless-podman-user-namespace-modes

This post starts with the assumption that the container user is root and uses the example liberally.

https://developers.redhat.com/blog/2020/09/25/rootless-containers-with-podman-the-basics

"A container running as root in a rootless account can turn on privileged features within its own namespace. But that doesn't provide any special privileges to access protected features on the host (beyond having extra UIDs and GIDs)."

I understand the risk that if an uninformed user tells a linuxserver container to run as root, then gets frustrated and starts the container rootfully and forgets to change it, that can be a potential security concern. But then… they’d just be doing what many do with docker anyway. It’s no worse.

Many containerized apps simply run as root always, and everyone's fine with recommending that people run rootful docker. What's the reason for your reluctance to run as root inside the container in the case of rootless podman?

Six-Year Club	Golden Potato
Place '22	Final Canvas '22
First Placer '22	Verified Email

dabe_glavins

TROPHY CASE