Channels DVR Docker - Working Directory Permissions Keep Changing

Channels DVR Server
#1

I've been running Channels as a docker container for years now. I'm not sure when this started, but for some reason, the latest symlink target (/2025.02.19.1823 in my case) and its contents keeps getting its permissions changed. Nothing on my side is toughing it, and I think it might be the act of updating that is doing it. For whatever reason, the permissions on the current latest directory get set to rw-rw---- (660). When this happens ffprobe fails on any scans it does, permission failure

Anyone else have an issue like this?

#2

I think i've recognized a pattern. It seems whenever new media is found and one of the binaries in that directory is called, something is changing permissions on that whole directory and its contents. The older "latest directories" never seem to get touched, whereas the current/latest version directory's permissions get changed anytime anything in there is called.

To give an example, as a test, I set the entire channels config directory to 777 (rwxrwxrwx). It stays that way until new media is detected, and it gets set to rw-rw----- by, I have to assume, Channels DVR server. This results in ffprobe failing, media not getting metadata assigned, and any transcoding failing (ffmpeg).

Any help with this would be greatly appreciated. I'm not sure when this new behavior was introduced, but I noticed the behavior with 2025.01.18.0528, if that helps any. It, effectively, makes Channels DVR unusable for new media-- I have to manually chmod that directory back whenever I notice problems.

If this is the case, is there anyway to suppress that permission change behavior?

#3

What system are you running docker on?
Did you update docker on it recently?

#4

Host: Ubuntu 24.04
Docker: 27.4.1 -- not recently updated

This is the strangest thing, and a real pain :slight_smile:

#5

Check the latest directory owner and permissions from Ubuntu and then again from inside the container. What does the command line or compose look like for the container.

#6

I'm actually not mounting on the Ubuntu host. I'm using an NFS volume mount defined in compose. Ownership wise, from within the container and on the fileserver seem fine. I'm going to keep a look and next time the permissions get changed, I'll check the ctime and compare to logs in channels... maybe I'll see something the server is doing at the same time the permissions were changed.

How i'm mounting this share:

volumes:
      #####NFS Volumes#####
      - #other media mounts (Movies, DVR, etc.) also mounted as NFS volumes
      - type: volume
        source: vol_channels-dvr_data
        target: /channels-dvr
        volume:
          nocopy: true

vol_channels-dvr_data:
    driver: local
    driver_opts:
      type: "nfs"
      o: addr=192.168.50.20,nolock,soft,rw
      device: ":/var/nfs/shared/docker_data/channels-dvr/config"
#7

The /channels-dvr mount should not be using a network FS. It can just be a local volume.

1 Like
#8

Sure. It shouldn't be, but it can be... right? It's worked this way for a very long time. I think my question still stands, from the Channels DVR server pov (code/script wise), with regards to is something explicitly coded to check/modify permissions in the latest directory? Looks like it did it right at the top of the hour.

#9

Nope nothing like that exists in Channels DVR

#10

If you look at the setup.sh script, it only marks files as executable when installed/updated.
And creates a latest symlink.

chmod +x channels-dvr/$version/*
ln -nsf $version channels-dvr/latest
...
chmod +x channels-dvr/*.sh
#11

Gotcha... thanks.

#12

yep, and I see that exact behavior on install and update. Like clockwork, right at 1600 (my time) hours, permissions on just the latest directory get changed. I will keep searching for the culprit. I just can't think of anything that has changed on my side.

#13

Are the permissions changing on the symlink itself, or on the directory it points to?
I thought symlinks were always 0777
Capture

/channels-dvr # ls -l latest
lrwxrwxrwx    1 root     root            15 Mar  7 08:56 latest -> 2025.03.06.2119
/channels-dvr # stat latest
  File: 'latest' -> '2025.03.06.2119'
  Size: 15              Blocks: 0          IO Block: 4096   symbolic link
Device: f801h/63489d    Inode: 83361796    Links: 1
Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2025-03-09 11:07:51.714949051 -0700
Modify: 2025-03-07 08:56:43.275835076 -0800
Change: 2025-03-07 08:56:43.275835076 -0800
/channels-dvr # cd latest
/channels-dvr/latest # ls -l
total 312768
-rwxr-xr-x    1 root     root      74240184 Mar  7 08:56 channels-dvr
-rwxr-xr-x    1 root     root      17918456 Mar  7 08:56 comskip
-rwxr-xr-x    1 root     root     138152088 Mar  7 08:56 ffmpeg
-rwxr-xr-x    1 root     root      69184134 Mar  7 08:56 ffmpeg-dl
-rwxr-xr-x    1 root     root      20742680 Mar  7 08:56 ffprobe
-rwxr-xr-x    1 root     root           376 Mar  7 08:56 linux-x86_64.sha256
-rwxr-xr-x    1 root     root            15 Mar  7 08:56 prerelease
-rwxr-xr-x    1 root     root            15 Mar  7 08:56 version
/channels-dvr/latest # stat ffprobe
  File: ffprobe
  Size: 20742680        Blocks: 40520      IO Block: 4096   regular file
Device: f801h/63489d    Inode: 191922398   Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2025-03-08 11:00:01.214754057 -0800
Modify: 2025-03-07 08:56:39.740772405 -0800
Change: 2025-03-07 08:56:39.740772405 -0800
#14

It is highly recommended to put the binaries and database on local storage. Backups are made onto your NFS volume alongside your recordings.

Sounds like something changed on the nfs or docker side, not sure why permissions would be changing randomly.

There are tools like bpf opensnoop that can show who is manipulating files.

#15

Maybe. It's just odd to me that out of all the services that I run, Channels is the only that has this issue. Local isn't an option for me as I run channels in a docker swarm. For fun, I pointed that directory to a local bind mount that is mounted to a ceph filesystem-- same issue.

I'm going to spin up a test container, later, no swarm, on a single node and do a straight bind mount to the local fs, just to see if I can reproduce with a totally local mount.

@chDVRuser, yes, the symlink is 0777. The issue is the directory it points to keeps getting its permissions changed, every hour, and the binaries inside the target directory are getting set to rw. Nothing else gets touched

#16

So, it is not a Channels DVR thing. Turns out Ubiquiti in the UNAS Pro doesn't allow the execute bit to be set on shares. The NAS is removing the permission, and there doesn't seem to be a way to undo it. Sorry for all the back and forth.

Now, if you wanted to make Channels include all the ffmpeg binaries as part of the image, like other media apps do... that would help solve this :wink:

1 Like
#17

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.