Error: unable to find bedrock server process

[StevenLiew]

This is related to #327

I am experiencing the same issue, but my setup is different - I am running on Synology 923+ Container Manager.

send-command gamerule showcoordinates true

Error messages as follows:

find: '/proc/1/exe': Permission denied
find: '/proc/11/exe': Permission denied
ERROR: failed to search for bedrock server process

Thanks in advance!

Here are some screenshots:

[itzg]

Hmm, that's odd that the root user within the container is getting permission denied. Do you know if Container Manager is running rootless docker?

[StevenLiew]

Thanks for the quick response! I'm relatively new to dockers, but here are some updates that may provide more clues.

I moved away from docker compose and went to create a new test server, running as the root:

sudo docker run -d -it --name=minecraft-test \
-p 19132:19132/udp \
-v /volume1/docker/mc-test:/data \
-e EULA=TRUE \
-e DIFFICULTY=peaceful \
-e GAMEMODE=survival \
-e UID=1026 \
-e GID=100 \
-e SERVER_NAME="Liew Family Server" \
-e LEVEL_SEED=-698960834 \
--net=containers_network \
--ip=192.168.1.228 \
--restart always \
itzg/minecraft-bedrock-server

First I added UID/GID of the user account which has read/write access to docker folder into ENV, but to no avail.

Then I moved onto SSH and tried to send the command directly:

sudo docker exec minecraft-test send-command gamerule showcoordinates true

I received the same error:

find: '/proc/1/exe': Permission denied
find: '/proc/11/exe': Permission denied
ERROR: failed to search for bedrock server process

Attaching the docker, however works:

StevenLiew@LIEW_NAS:~$ sudo docker attach minecraft-test
gamerule showcoordinates true
[2023-06-20 04:26:22:957 INFO] Game rule showcoordinates has been updated to true
read escape sequence

[itzg]

I can't recreate this issue. It must be something specific to your system and/or Synology. To help you troubleshoot can you provide output of these:

sudo docker exec minecraft-test id
sudo docker exec minecraft-test bash -c 'ls -l /proc/*/exe'

[StevenLiew]

Please see the results below: (I made some tweaks and hence the difference in container name)

StevenLiew@LIEW_NAS:~$ sudo docker exec minecraft-bedrock id
uid=0(root) gid=0(root) groups=0(root)
StevenLiew@LIEW_NAS:~$ sudo docker exec minecraft-bedrock bash -c 'ls -l /proc/*/exe'
ls: cannot read symbolic link '/proc/1/exe': Permission denied
ls: cannot read symbolic link '/proc/11/exe': Permission denied
lrwxrwxrwx 1 root root  0 Jun 20 15:47 /proc/1/exe
lrwxrwxrwx 1 1026 users 0 Jun 20 15:47 /proc/11/exe
lrwxrwxrwx 1 root root  0 Jun 20 15:47 /proc/17066/exe -> /bin/bash
lrwxrwxrwx 1 root root  0 Jun 20 15:48 /proc/17109/exe -> /bin/ls
lrwxrwxrwx 1 root root  0 Jun 20 15:47 /proc/65/exe -> /bin/bash
lrwxrwxrwx 1 root root  0 Jun 20 15:48 /proc/self/exe -> /bin/ls
lrwxrwxrwx 1 root root  0 Jun 20 15:48 /proc/thread-self/exe -> /bin/ls
StevenLiew@LIEW_NAS:~$

[itzg]

Thanks! I'm really not sure how to proceed though. If a root user does not have permissions to read a symbolic link, then the current solution can't function. I'm afraid docker attach will have to be the method used on your system.

[StevenLiew]

No worries, thanks for the help anyway. I'll stick to using docker attach ;)

[NickdeK]

I'm having the same issue as well with a newly setup raspberry pi. The problem is I want to make some basic shell scripts that changes the game difficulty based on time, I can't find a way to do that with docker attach.

[merval]

I'm having the same issue. I have a local directory mounted as /data, but when I remove that mount everything works correctly.

I wonder if somehow it's detecting /data has different UID/GUID and that thwarts the servers ability to talk to the pid.

[merval]

Okay, so I found a way around this issue. The directory you are using with your volume mount, needs to be owned by root:root. The logs indicate it's using the UID and GID to determine the permissions:

time="2023-10-18T18:08:44Z" level=debug msg="Using /data to match uid and gid"
time="2023-10-18T18:08:44Z" level=debug msg="Resolved UID=1000 from match path"
time="2023-10-18T18:08:44Z" level=debug msg="Resolved GID=1000 from match path"

Using a non-root owned directory for your volume will cause /data to be owned by the UID:GID it finds. The procs are even owned weird.

Here is what it looks like when you have a non-root owned directory:

root@008f67cab91b:/data# send-command help
find: '/proc/1/exe': Permission denied
find: '/proc/12/exe': Permission denied
ERROR: failed to search for bedrock server process

root@008f67cab91b:/data# ls -lah /proc/  
total 4.0K
dr-xr-xr-x 373 root root    0 Oct 18 18:23 .
drwxr-xr-x   1 root root 4.0K Oct 18 18:23 ..
dr-xr-xr-x   9 root root    0 Oct 18 18:23 1
dr-xr-xr-x   9 1000 1000    0 Oct 18 18:24 12

Even if I attempt to interact with the proc that is owned by 1000:1000 I get a permissions error.

For now, I'll just have my directory owned by root:root.

[bb-Ricardo]

According to this issue https://github.com/moby/moby/issues/6800 it is sufficient to add --cap-add=SYS_PTRACE to your docker command. Or add this to your docker-compose service of your minecraft server:

cap_add:
  - SYS_PTRACE

[gimmelovn]

Okay, so I found a way around this issue. The directory you are using with your volume mount, needs to be owned by root:root. The logs indicate it's using the UID and GID to determine the permissions:

time="2023-10-18T18:08:44Z" level=debug msg="Using /data to match uid and gid"
time="2023-10-18T18:08:44Z" level=debug msg="Resolved UID=1000 from match path"
time="2023-10-18T18:08:44Z" level=debug msg="Resolved GID=1000 from match path"

Using a non-root owned directory for your volume will cause /data to be owned by the UID:GID it finds. The procs are even owned weird.

Here is what it looks like when you have a non-root owned directory:

root@008f67cab91b:/data# send-command help
find: '/proc/1/exe': Permission denied
find: '/proc/12/exe': Permission denied
ERROR: failed to search for bedrock server process

root@008f67cab91b:/data# ls -lah /proc/  
total 4.0K
dr-xr-xr-x 373 root root    0 Oct 18 18:23 .
drwxr-xr-x   1 root root 4.0K Oct 18 18:23 ..
dr-xr-xr-x   9 root root    0 Oct 18 18:23 1
dr-xr-xr-x   9 1000 1000    0 Oct 18 18:24 12

Even if I attempt to interact with the proc that is owned by 1000:1000 I get a permissions error.

For now, I'll just have my directory owned by root:root.

I'm seeing something similar eluding to this also and wondering if it's a subuid/subgid mapping issue -- I'm still in denial that the directory must be owned by root:root -- still looking for a rootless solution -- I get the following when attempting to run the container:

time="2023-11-08T18:18:09Z" level=debug msg="Using /data to match uid and gid"

time="2023-11-08T18:18:09Z" level=debug msg="Resolved 1002 from environment variable UID"

time="2023-11-08T18:18:09Z" level=debug msg="Resolved 1001 from environment variable GID"

time="2023-11-08T18:18:09Z" level=info msg="Skipping uid/gid change since current user is not root"

[TaylorMichaelHall]

I ran into this when restoring a volume mount from a restic backup.

sudo chown -R root:root ./bedrock-data did resolve