3 posts were merged into an existing topic: Docker nvidia
I experienced this and was able to authenticate locally, but
what does this mean. You can't connect or authenticate using a local client?
Locally, clients do not use authentication. So, if the server is rejecting local requests, then the clients will not be able to connect.
Having issues with my dockers running under Windows 11 and WSL2 but those on ubuntu the network: host option had no issues
Are you seeing this in the DVR log when you try to connect?
All I see is Running Channels DVR..
However unlike with -p option I don't see the port listening with the network: host command
In doing research I've read where someone stated "If you want host networking, you can uninstall Docker Desktop, and install Docker Engine natively inside WSL2" so may need to try that instead
It will be in the DVR log
Docker Bridge network with docker run -p 8489:8089
2024/01/05 21:54:54.058010 [SYS] Starting Channels DVR v2024.01.05.2044 (linux-x86_64 pid:7) in /channels-dvr/data
2024/01/05 21:54:54.067125 [SYS] Started HTTP Server on 8089
Docker Host network with channels-dvr -port=8489
in run.sh
OR docker run with -e CHANNELS_PORT=8489
2024/01/05 21:59:24.382653 [SYS] Starting Channels DVR v2024.01.05.2044 (linux-x86_64 pid:7) in /channels-dvr/data
2024/01/05 21:59:24.414253 [SYS] Started HTTP Server on 8489
I can also see the listening ports with netstat
root@DS1019PLUS:~# netstat -vpntel | grep '../latest/ch'
tcp6 0 0 :::8089 :::* LISTEN 0 192088701 2866/../latest/chan
tcp6 0 0 :::8189 :::* LISTEN 0 192090979 5868/../latest/chan
tcp6 0 0 :::8190 :::* LISTEN 242120 192093301 13521/../latest/cha
tcp6 0 0 :::8289 :::* LISTEN 0 192091224 9144/../latest/chan
tcp6 0 0 :::8389 :::* LISTEN 0 192086719 29910/../latest/cha
tcp6 0 0 :::8489 :::* LISTEN 0 192735274 9880/../latest/chan
I can run fine with only the -p option, but then I get the authentication screen.
It is when I try to migrate to the --network=host that there is an issue
You cannot run the -p option along with the --network=host option as it gives the following message:
WARNING: Published ports are discarded when using host network mode
which then results in the issue
Again this is only an issue in WSL and Docker Desktop on Windows 11,
not on Ubuntu
The -p
option being discussed is for the channels-dvr
binary running inside the container. It is completely different from the --publish
/-p
option passed to the docker
binary.
A new environment variable was added to allow this setting to more easily be passed to the binary in the container. To change the port your server is going to listen on, add -e CHANNELS_PORT=…
to your Docker command line.
So what is the "issue". You never said?
My understanding is you cannot run a docker container using host networking mode (--network=host) on Docker for Mac or Docker for Windows Channels — Channels DVR Server
- Neither Docker for Mac nor Docker for Windows support
--net=host
. When running on these platforms, you'll have to connect to Channels DVR Server by IP address from Channels. You can do this in the Settings tab of the Channels Apps.
Hence my first post in this thread
When will more details about the vulnerability be posted now a fix has been released?
I'd like to understand why this is required when I do not expose Channels externally to my network.
When it's released to the stable channel
See ⚠️ Security Resolution Incoming ⚠️ - #53 by eric
Only required if you don't want to authenticate locally in a web browser to access the dvr server or you want to use clients locally. Their chosen mitigation is to prevent local access to a channels server running in a docker container using bridge mode networking (where there's an iptables issue).
I understand what the -p option does, and I am using the new variable as well however I still cannot get the URL to open when using the --network=host option
Does not work - no URL opens
docker run \
--detach \
--name=channels-dvr-8092 \
--restart=unless-stopped \
--network=host \
--env TZ=America/Denver \
--env CHANNELS_PORT=8092 \
--volume /mnt/disk/d/dvr_8092/config:/channels-dvr \
--volume /mnt/disk/d/dvr_8092/recordings:/shares/DVR \
fancybits/channels-dvr:tve
URL opens but requires authentication
docker run \
--detach \
--name=channels-dvr-8092 \
--restart=unless-stopped \
-p 8092:8092 \
--env TZ=America/Denver \
--env CHANNELS_PORT=8092 \
--volume /mnt/disk/d/dvr_8092/config:/channels-dvr \
--volume /mnt/disk/d/dvr_8092/recordings:/shares/DVR \
fancybits/channels-dvr:tve
This is exactly the issue which is why I'm mentioning this as using the any port publishing sends me to the authentication and the network=host option doesn't provide the URL
You missed the earlier discussion further up the thread. This is only for mitigation on Linux hosts using bridged networking. Windows and macOS hosts are likely not affected:
(Also, Docker on Windows and macOS does not support host-mode networking, so trying to use that option on those platforms is pointless.)
I did see the discussion - the point is that it is NOT working correctly and ARE affected if I have to locally request authentication on dockers under windows
I guess in your case the Docker implementation in Docker for Windows using bridge networking is NOT working correctly
Running Docker on Ubuntu. I have pulled the latest Docker image. I added the network=host parameter, but am not able to connect to the container at localhost:8089/admin/settings/status. Here is my Docker CLI:
docker run \
--env=PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \
--name=channels_dvr_8089 \
--network=host \
--volume=/home/scott/channels-dvr:/channels-dvr \
--volume=/media/scott/dvr_data:/shares/DVR \
--volume=/channels-dvr \
--env=TZ=America/Chicago \
--env=CHANNELS_PORT=8089 \
--restart=unless-stopped \
--runtime=runc -d fancybits/channels-dvr:tve`shell
Did you have an issue running it in bridged network mode before you changed it?
You also don't need this if you're using the default port 8089
Remove this line.