teamspeak-linux-docker-images
teamspeak-linux-docker-images copied to clipboard
entrypoint.sh: line 50: can't create /var/run/ts3server/ts3server.ini: Permission denied :(
Here we go again.
Issue: https://github.com/TeamSpeak-Systems/teamspeak-linux-docker-images/issues/39#issue-521733909
Update from 3.10.2 to 3.11
This is happening to me as well.
Same for me. My ts3 servers are no longer starting.
You don't need to port /opt/ts3server/
, here's nothing important. All data is stored in /var/lib/mysql/
and /var/ts3server/
.
So you can do the following to save your configuration on host:
version: '3.1'
services:
teamspeak:
container_name: teamspeak
image: teamspeak:latest
volumes:
- "./ts3server:/var/ts3server/"
restart: always
ports:
- 9987:9987/udp
- 10011:10011
- 30033:30033
environment:
TS3SERVER_DB_PLUGIN: ts3db_mariadb
TS3SERVER_DB_SQLCREATEPATH: create_mariadb
TS3SERVER_DB_HOST: db
TS3SERVER_DB_USER: root
TS3SERVER_DB_PASSWORD: you_db_password
TS3SERVER_DB_NAME: teamspeak
TS3SERVER_DB_WAITUNTILREADY: 30
TS3SERVER_LICENSE: accept
db:
container_name: teamspeak_db
image: mariadb
restart: always
volumes:
- ./mysql:/var/lib/mysql
environment:
MYSQL_ROOT_PASSWORD: you_db_password
MYSQL_DATABASE: teamspeak
What does this comment have to do with the entrypoint being unable to create the server config file? The current image does not work on certain container environments with the changes of the permissions...
/opt/ts3server/ is never mounted to a volume here. Commit 666bbe0180fd64e330a63cabeff5dbe2bd89a6ce or 12ce1ade4fbc630e0126d863132d21b27a16330a probably broke the permissions...
I've already explained my setup in the link above. All my servers use namespace remapping to an user namespace to isolate them from the docker host. However, I want to attach all TS3 containers to the host network, because the TS3 server is not able to see the IPv6 address of an user, if the container is part of a docker network. All users will just share the IPv6 gateway of the docker network. You cannot assign containers to the host network within user namespaces. Therefore, i run the TS3 container within the root namespace.
See: Isolate containers with a user namespace
The problem is:
-
The Dockerfile sets the permissions for the folders with:
install -d -o ts3server -g ts3server -m 775 /var/ts3server /var/run/ts3server /opt/ts3server
= UID/GID 9987 -
I run the the container on a docker host with namespace isolation enabled. The ts3 container is attached to the root namespace.
-
I opened a shell within the TS3 container and looked at the owner of the folders:
~ $ cd /var/run/ts3server/
/run/ts3server $ ls -la
total 8
drwxrwxr-x 1 303595 303595 4096 Feb 5 14:08 .
drwxr-xr-x 1 293608 293608 4096 Feb 5 14:08 ..
- 293608 is the root ID of the user namespace (ID = 0)
- 303595 is obviously: 293608 + 9987
- Conclusion:
- The file permissions are the one of the user namespace.
- The processes run in the root namespace - well 9987 != 303595
- The whole stuff worked before the latest release, because the install command set the mode to 777
- Now it is set to 775
- My solution: I modified the entrypoint to change the owner of the 3 folders to ts3server. The entrypoint sets the permission during runtime and therefore, line 50 will not throw an error anymore. No idea if this is dirty... :) entrypoint.sh - first if block:
if [ "$1" = 'ts3server' -a "$(id -u)" = '0' ]; then
chown -R ts3server:ts3server /var/ts3server /opt/ts3server /var/run/ts3server
exec su-exec ts3server "$0" "$@"
fi
What does this comment have to do with the entrypoint being unable to create the server config file? The current image does not work on certain container environments with the changes of the permissions...
/opt/ts3server/ is never mounted to a volume here. Commit 666bbe0 or 12ce1ad probably broke the permissions...
Sorry my bad, I had a similar problem when I mounted /opt/ts3server as volume.
It happens to me as well.
But I only execute the container with a different user (different name and ID). So Heidus' solution would not work for me.
I think the way to get this sort of regression failure permanently fixed is to submit a test: https://github.com/docker-library/official-images/tree/master/test
Any updates? The issue has been around for 10 months....
We recently pulled the new Docker image version 3.13.6 and this issue started. We can use the image in version 3.13.3 without this issue. any updates on this? :-/
We are using rootless podman to start the image via compose-files.
For me a simple chmod +x
on the entrypoint.sh
worked. I guess it's pushed to this repo without executable permissions..
If someone should run into the same problem. I found a fix that worked for me.
volumes:
- ./data/:/var/ts3server/:Z
Just append the line where you define the bind mount for the volume with ":Z"
This will label the content inside the container with the exact MCS label that the container will run with, basically it runs chcon -Rt svirt_sandbox_file_t -l s0:c1,c2 /var/db where s0:c1,c2 differs for each container.
https://stackoverflow.com/questions/24288616/permission-denied-on-accessing-host-directory-in-docker
EDIT: On further investigation the Problem in my case comes from SELinux which is bundles with fedora server edition.
SELinux can be disabled with:
sudo setenforce 0
and reenabled with:
sudo setenforce 1