cannot run due to bedrock-entry.sh operation not permitted

[derelbenkoenig]

I am seeing this in the container logs:

DEBU[0000] Using /data to match uid and gid
DEBU[0000] Resolved UID=5000 from match path
DEBU[0000] Resolved GID=5000 from match path
FATA[0000] Failed to run sub-command                     error="fork/exec /opt/bedrock-entry.sh: operation not permitted"
DEBU[0000] Using /data to match uid and gid
DEBU[0000] Resolved UID=5000 from match path
DEBU[0000] Resolved GID=5000 from match path
FATA[0000] Failed to run sub-command                     error="fork/exec /opt/bedrock-entry.sh: operation not permitted"

this is running on an Ubuntu machine in digital ocean with this docker version:

root@minecraft-docker-01a:~# docker --version
Docker version 20.10.7, build 20.10.7-0ubuntu5~20.04.2

I am using this script to start the container:

#!/bin/bash

mkdir -p /var/lib/minecraft/data/
chown 5000:5000 /var/lib/minecraft -R

# -dit means detach, interactive, pseudo tty. This allows you to attach and detach from stdin
#
# 3G memory should leave some room within the 4G that the VM has?
#
docker run \
	-dit \
	--restart="on-failure" \
	-v /var/lib/minecraft/data:/data:Z \
	-p 19132:19132/udp \
	-u 5000:5000 \
	-e VERSION=LATEST \
	-e SEED="-479112237913370" \
	-e OPS="DerElbenkoenig" \
	-e OVERRIDE_OPS=true \
	-e EULA=TRUE \
	-e MEMORY=3G \
	--name minecraftserver \
	docker.io/itzg/minecraft-bedrock-server:latest

[derelbenkoenig]

Well. as it turns out, removing the -u 5000:5000 appears to have fixed this. but I'm not sure if that's what I want, because I think that means the whole container is running as root... maybe that's fine?

[itzg]

The startup system demotes the bedrock process to match the owner of the data volume, so it's ultimately not running as root even when you're leaving off the -u.

I will still investigate this a bit, because maybe I'm missing logic to skip the demotion if already running as the user.

[TrainAss]

[deleted] Commented in incorrect thread.

[itzg]

@derelbenkoenig sorry for the delay, I had forgotten to actually upgrade the demoter version in the image. Please re-pull the latest image and try that.

@TrainAss the variables are supposed to be UID and GID and this image doesn't perform any chmods on the data directory. You will need to prepare that directory with the corresponding ownership.

[TrainAss]

@itzg I apologize, I commented on the wrong thread. I'm not having the same issue as Op. My issue is different.

[derelbenkoenig]

@itzg I'll give it a shot next time I restart my server, thanks for the reply!