Closed vlastaw closed 8 months ago
Same behaviour on Synology DS920+, OS is DSM 7.2.1-69057 Update 3
I'm unfamiliar with QNAP or Synology, but it's normal in containers to keep the default ports used by the bundled apps, here Nginx. What you are supposed to do is bind these internal ports to another one on your host, such as 8080 for instance. There must be a way to do that, I can't see QNAP or Synology not allowing such a basic feature of Docker.
You are of course right, there is a misunderstanding.
This
docker run -d -p 8080:80 ghcr.io/jellyfin/jellyfin-vue:unstable
as well as a docker compose
jellyfin-vue:
image: ghcr.io/jellyfin/jellyfin-vue:unstable
container_name: jellyfin-vue
hostname: jellyfin-vue
environment:
- DEFAULT_SERVERS=https://jellyfin.mydomain.tld
- DISABLE_SERVER_SELECTION=1
ports:
- 8080:80
networks:
- web
restart: unless-stopped
are leading to this error
I'm unfamiliar with QNAP or Synology, but it's normal in containers to keep the default ports used by the bundled apps, here Nginx. What you are supposed to do is bind these internal ports to another one on your host, such as 8080 for instance. There must be a way to do that, I can't see QNAP or Synology not allowing such a basic feature of Docker.
Oh, thank you. But you might have noticed, that I am already running Feishin in Docker on the same device, so I probably know, how to map ports in the virtual network. That's not the issue.
To my understanding the issue is the container itself, because its set to listen on port 80, but that (<1024) requires Privileged access in Linux. So no matter which port I map to it from the host, it won't work, because the guest machine always listens on 80. Feishin's Docker container (its web server) listens on port 9180, which is OK. Of course that's just my speculation, there might be a whole other issue. However it's not the host > guest port mapping. What happens, at least what the GUI displays, is that the guest machine is assigned a natted IP address (10.0.3.3) and loses it in a second (0.0.0.0).
There might be something up, with the internal 80 port not helping. Are you able to run the default Nginx image from DockerHub? It uses the 80 port to by default, maybe it'll help us point to something in our configuration.
PS: How was I able to see that you've mapped the port in your initial post? Sorry if I've missed it anyway.
Thank you for the tip. It seems I can.
/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/ /docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh 10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf 10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf /docker-entrypoint.sh: Sourcing /docker-entrypoint.d/15-local-resolvers.envsh /docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh /docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh /docker-entrypoint.sh: Configuration complete; ready for start up 2024/03/04 17:38:29 [notice] 1#1: using the "epoll" event method 2024/03/04 17:38:29 [notice] 1#1: nginx/1.25.4 2024/03/04 17:38:29 [notice] 1#1: built by gcc 12.2.0 (Debian 12.2.0-14) 2024/03/04 17:38:29 [notice] 1#1: OS: Linux 4.2.8 2024/03/04 17:38:29 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 65535:65535 2024/03/04 17:38:29 [notice] 1#1: start worker processes 2024/03/04 17:38:29 [notice] 1#1: start worker process 30 2024/03/04 17:38:29 [notice] 1#1: start worker process 31 2024/03/04 17:38:29 [notice] 1#1: start worker process 32 2024/03/04 17:38:29 [notice] 1#1: start worker process 33 10.0.3.1 - - [04/Mar/2024:17:38:29 +0000] "\x16\x03\x01\x00\xEA\x01\x00\x00\xE6\x03\x03\x84%z\x19\xB8\x93\xF6\x928\xED|:\xD5\xFCW\xB8D\xACgfn\xEFP(\xDC0\xFB\xE0Z\x02\x12\x9C \x10\x88$\x83\xAF\xDA*\x9E\xAAjtG\x84\xD8G\x06\xBA\x90\xC38_\xD5
\xEAj\x82\x8F\xB3%\xDAt\xDF\x00&\xC0+\xC0/\xC0,\xC00\xCC\xA9\xCC\xA8\xC0\x09\xC0\x13\xC0" 400 157 "-" "-" "-"
10.0.3.1 - - [04/Mar/2024:17:38:29 +0000] "GET / HTTP/1.1" 200 615 "-" "Go-http-client/1.1" "-"`
Does it make sense to bind nginx to port 80? I mean if it is running in docker, you can just map it to a different port anyway when running the container.
I initially thought the issue was that nginx coldn't bind to 80 inside the container, regardless of whatever port was used in the host. However, nginx's image is working fine and the issue it's not in this container?
The image @vlastaw used is the stock nginx container, which starts up as root, so it can bind to 80. This is the official unprivileged image: https://hub.docker.com/r/nginxinc/nginx-unprivileged, which binds to 8080.
Well, then my theory of unpriviliged access to ports <1024 might be right, when even nginx is set not to use <1024 with unpriviliged users.
@mhamzahkhan @vlastaw Can you guys try the builds from #2247
By accessing the checks' summary, you can download the exported docker image in the Artifacts section
Yep looks like it works for me
I tried 2024-03-05.63981e1 and unfortunately it behaves the same. Loops these:
`2024/03/06 02:32:50 [emerg] 1#1: bind() to 0.0.0.0:80 failed (13: Permission denied) nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) ==== Starting Jellyfin Vue setup ====
Writing data to /usr/share/nginx/html/config.json... DEFAULT_SERVERS value: ALLOW_SERVER_SELECTION value: true ROUTER_MODE value: history
==== Setup finished! ====
2024/03/06 02:32:53 [emerg] 1#1: bind() to 0.0.0.0:80 failed (13: Permission denied) nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied) ==== Starting Jellyfin Vue setup ====
Writing data to /usr/share/nginx/html/config.json... DEFAULT_SERVERS value: ALLOW_SERVER_SELECTION value: true ROUTER_MODE value: history
==== Setup finished! ====`
This fix seems to work. I have Downloaded the Image from https://github.com/jellyfin/jellyfin-vue/actions/runs/8156492442/artifacts/1298415993 and loaded it:
docker load < docker_image.tar
149c5e2d17c1: Loading layer [==================================================>] 5.698MB/5.698MB
6cbb65340ca2: Loading layer [==================================================>] 3.584kB/3.584kB
8ec2769da802: Loading layer [==================================================>] 5.12kB/5.12kB
55bd93303ff0: Loading layer [==================================================>] 38.4kB/38.4kB
d9e08de748ba: Loading layer [==================================================>] 2.358MB/2.358MB
Loaded image: jellyfin/jellyfin-vue:pr-build
I can start the image:
docker run -d -p 8080:80 c6062664f9d4
Logs are looking fine:
docker logs -f ac1b08b896083cf751c6b1fb64f888296ef697f73620b326aefc04a714e48a41
==== Starting Jellyfin Vue setup ====
Writing data to /usr/share/nginx/html/config.json...
DEFAULT_SERVERS value:
ALLOW_SERVER_SELECTION value: true
ROUTER_MODE value: history
==== Setup finished! ====
2024/03/06 08:27:21 [notice] 1#1: using the "epoll" event method
2024/03/06 08:27:21 [notice] 1#1: nginx/1.24.0
2024/03/06 08:27:21 [notice] 1#1: built by gcc 12.2.1 20220924 (Alpine 12.2.1_git20220924-r4)
2024/03/06 08:27:21 [notice] 1#1: OS: Linux 4.4.302+
2024/03/06 08:27:21 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 1048576:1048576
2024/03/06 08:27:21 [notice] 1#1: start worker processes
2024/03/06 08:27:21 [notice] 1#1: start worker process 9
2024/03/06 08:27:21 [notice] 1#1: start worker process 10
2024/03/06 08:27:21 [notice] 1#1: start worker process 11
2024/03/06 08:27:21 [notice] 1#1: start worker process 12
192.168.11.65 - - [06/Mar/2024:08:27:42 +0000] "GET / HTTP/1.1" 200 1949 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36" "-"
192.168.11.65 - - [06/Mar/2024:08:27:42 +0000] "GET /shared-CVtkxrq9.js HTTP/1.1" 200 1257 "http://192.168.21.153:8080/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36" "-"
And i am able to reach the webinterface
Unfortunately QTS won't install that file.
I guess the best way to test it yourself would be to build locally the image on your PC from the MR, then save it to tar from there and push it to your QNAP.
@vlastaw My guess is that the image is amd64 only and your NAS might be arm64.
I'm merging the PR, it helped others, so probably you too (and that way you have a handy arm image to test). In case it still doesn't work after the merge, please let me know so I can reopen the issue.
FWIW, this snippet in the docker-compose
service allows not running the main nginx process as root:
cap_add:
- CAP_NET_BIND_SERVICE
user: 101:101 # nginx (inside the container)
@neingeist The docker images no longer run as root fyi.
@neingeist The docker images no longer run as root fyi.
If you would start it .e.g. using docker run
, it would start up as root, bind to :80 and then drops down to nginx. But last time I checked, you can't start it up as e.g. 101:101 (= nginx in the image), unless you add CAP_NET_BIND_SERVICE.
@neingeist Which system?
@neingeist Which system?
I checked again, on my Fedora 39 system there is no problem. Apparently Docker now lowers the privileged port range so you can run e.g. docker run -ti --rm=true -u 101:101 ghcr.io/jellyfin/jellyfin-vue:unstable.2024-09-20.28d1163
(running the image using uid 101 right away).
On my Synology NAS this did not work and I had to add CAP_NET_BIND_SERVICE
if I wanted to run as uid 101 right away. (I am not investigating the reasons, as I have an update to the NAS pending anyway.)
@neingeist I assumed you were using a really old version because I recall this not being the case after a long time. After further investigation, I discovered this has been the case since moby/moby#41030 (released with Docker 20.10) in 2020, almost 4 years ago and it's completely EOL and out of security updates since a year, so you should update your NAS ASAP 😅😅.
Besides being EOL, even if it still were supported as LTS (no LTS without that change is even suppirted though), I don't think there's a reason to stay in inferior versions in Docker really, so I don't think nothing should be changed in Jellyfin Vue's images.
@ferferga Wasn't necessarily suggesting changing anything, just providing a workaround in case anyone tries the same as me :)
It's not only the Docker version, the kernel also needs to have /proc/sys/net/ipv4/ip_unprivileged_port_start
for it to work.
Description of the bug
Docker on Container station on QNAP QTS won't run the container. Throws error:
2024/02/25 00:32:26 [emerg] 1#1: bind() to 0.0.0.0:80 failed (13: Permission denied) nginx: [emerg] bind() to 0.0.0.0:80 failed (13: Permission denied)
This probably is an issue with port 80 and default Linux handling of privileged ports (<1024). I would suggest to set another default port for the app (>1024).
Setting the container to run in Privileged mode does not solve the issue. Even though I would not like to run it that way anyway.
My environment is otherwise OK - I run Feishin in Docker too.
Thanks for any solution.
Steps to reproduce
Import container (NAS virtual network), map ports (in my case 19181 > 80), try to run container.
Runs > throws error > container status "other" instead of running.
Expected behavior
Run.
Logs
Screenshots
No response
Platform
Linux
Browser
Edge
Jellyfin server version
10.8.13
Additional context
No response