s8n-ru 0dad38e02e Initial commit: racked.ru Minecraft server config snapshot

Captures live config state of nullstone Purpur 1.21.11 server:
- docker-compose.yml (itzg/minecraft-server image, MODRINTH_PROJECTS + PLUGINS lists)
- All plugin configs under live-server/plugins/ (no DBs, no jars, no world data)
- Server core: bukkit.yml, spigot.yml, purpur.yml, paper-global.yml, paper-world-defaults.yml, server.properties

Excluded via .gitignore:
- World data (world/, world_nether/, world_the_end/, auth_limbo/)
- Sensitive: AuthMe DB (password hashes), Lands DB, CoreProtect DB, Essentials userdata
- Jars (auto-fetched), logs, caches, .paper-remapped

2026-04-30 18:33:38 +01:00

2.1 KiB

Raw Blame History

Permissions / userns-remap quirk

Symptom

Container restart-loops on first boot. Logs show:

[init] Changing ownership of /data to 1000 ...
chown: changing ownership of '/data/server.properties': Operation not permitted
[init] Running as uid=1000 gid=1000 with /data as 'drwxrwxr-x 4 65534 65534 4096 /data'
/image/scripts/start-configuration: line 87: /data/.rcon-cli.env: Permission denied

Files appear inside container as 65534:65534 (nobody:nogroup) even though host shows them as 1000:1000.

Cause

Docker daemon on this host runs with userns-remap enabled (/etc/docker/daemon.json has "userns-remap": "default"). This maps container UID 1000 → some host UID like 100000+1000=101000. Files owned by host UID 1000 (user:user) are not owned by the remapped container UID, so:

They show up as nobody:nogroup (65534) inside the container.
Container can read world-readable files but can't write unless dir is o+w.
Init script can't chown (host kernel blocks it — bind mount, foreign UID).

Fix

chmod -R 777 /opt/docker/minecraft

This is what the original deployment used (verified: old dir was drwxrwxrwx 12 user user). Container can now write logs, world data, plugin configs, RCON env file.

Why not disable userns-remap?

It's a host-wide hardening setting, kept for the rest of the Docker stack on nullstone. Per-container userns override (userns_mode: "host" in compose) is possible but defeats the security benefit for this container.

Alternative: named volume

volumes:
  - mc-data:/data
volumes:
  mc-data:

Docker creates the volume owned by the remapped UID directly, no chmod needed. Trade-off: harder to inspect/edit configs from host (must docker cp or bind-mount inspect).

This repo sticks with bind mount + chmod 777 for operator ergonomics.

Cosmetic chown spam (non-blocking)

Even with chmod 777, init still logs chown: ... Operation not permitted for every file. Server starts and runs fine — kernel just won't let init re-claim ownership across the userns boundary. Ignore.

2.1 KiB Raw Blame History