So I’ve been looking into running my own BBS and found out that Synchronet can be run in a docker container. Easy! …. Yeah if I had paid attention.

So I use OpenMediaVault as my NAS. It’s light, it’s easy, it has a web interface to manage docker compose. So I quickly scan the compose file for Synchronet and the drop it in. Spin it up, start playing with it. Cool stuff right.

Then I discover, unrelated to anything I was doing here, that I can’t run sudo anymore:

sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set

Haha, fuck, what? Okay. What? While investigating that I found that my entire root filesystem had been chown‘d to the docker user and group…..

So what happened?

I didn’t read close enough. The compose file maps $PWD to the bbs’ data directory inside the container. I GUESS that when running via the compose service as configured from the web page, $PWD either is set to root, or more likely isn’t set to anything at all. That means anything operating on "$PWD/" is just operating on "/"!

Always always always read everything closely. I didn’t expect an officially provided compose file to rely on the present working directory variable. Usually these things have like a unique variable that you define or overwrite, or some placeholder path.

It’s been a time and a half trying to undo this mess. We used the install disc to get a recovery environment where we could use chroot to set permissions, ownership, flags, and reinstall core software to fix things.

I’m still unfucking it. I’m sure it’s fucked up the samba shares. It had some annoying effects on my other docker containers I rely on like jekyll and syncthing.

I’m sure it’ll be something I’ll be undoing in bits and pieces as I keep discovering small problems

I can’t even blame linux for this. This was just me not paying attention

😪