Privacy & Security pop-ups, when updating CDVR server on macOS Sequoia+

Channels DVR Server Troubleshooting
#5

The important thing is that you brought this pattern into awareness now. At least you have a backup plan in case something gets hosed using VPN or tailscale and remote desktop.

Im thankful you brought this up, so I (and others)wont just blindly do an update server from my phone while driving - which used to be very fast and convenient.

For now, until apple smooths out these privacy and secirity popups we all should be more aware.

Im using external disks for channels, and a different disk for my portainer stacks and other things.

I can confirm Im getting this popups running other applications, its nuts.

Yesterday I got one just to run terminal, which of course Ive been using for a very long time. Weird and annoying

#6

@Fofer

I wrote a helper script and made it executable on boot up that emails me when channels cant find a file. it parses the channels log. Its kind of a hack, but at least its a strategy to have a soft landing for these kinds of issues.

Happy to share!

@maddox

Do you have any advice for us users regarding MACOS26? Im going to hold off until the dust settles, but Im interested if you have any insight.

#7

In my case, with a separate removable disk volume dedicated to the DVR, it appears that the new executable needs to be authorized to access "Files & Folders" or "Full Disk Access" (System Settings > Privacy & Security). This seems to be the case after an automatic update even though the new executable winds up in the same place the previous one did: ~Library > Application Support > ChannelsDVR > latest. I guess MacOS keeps track of the actual executable file that was allowed access and knows the new one is different though it has the same filename & location.

Auto update for Channels DVR screwing up recordings, can it be disabled?
#8

I get flashbacks

#9

Isn't latest a directory symlink pointing to the new version directory?
i.e. ~Library > Application Support > ChannelsDVR > latest
points to ~Library > Application Support > ChannelsDVR > 2025.08.24.0217
And the directory the symlink points to changes with each update.
It is on Linux.

#10

I'm running the server on MacOS and "latest" appears to be an actual folder. The previous versions all appeared in their own folders with the date/time naming convention you mentioned. I moved all those just to be sure and restarted the server without any issues.

#11

Run this command in Terminal and it will show that latest is a symbolic directory link

ls -l ~Library/Application\ Support/ChannelsDVR/latest

Looks like this in Linux

$ ls -l /volume1/docker/channels-dvr-8089
total 28
drwxrwxrwx+ 2 root  root  4096 Aug 11 18:55 2025.08.09.2304
drwxrwxrwx+ 2 root  root  4096 Aug 14 14:07 2025.08.14.0637
drwxrwxrwx+ 2 root  root  4096 Aug 16 08:54 2025.08.15.1429
drwxrwxrwx+ 2 root  root  4096 Aug 19 11:56 2025.08.19.0525
drwxrwxrwx+ 2 root  root  4096 Aug 20 18:51 2025.08.21.0013
drwxrwxrwx+ 2 root  root  4096 Aug 23 11:19 2025.08.21.1637
drwxrwxrwx+ 9 root  root  4096 Aug 17 09:40 data
lrwxrwxrwx+ 1 root  root    15 Aug 23 11:19 latest -> 2025.08.21.1637

$ ls -l /volume1/docker/channels-dvr-8089/latest
lrwxrwxrwx+ 1 root root 15 Aug 23 11:19 /volume1/docker/channels-dvr-8089/latest -> 2025.08.21.1637
#12

The executables are cryptographically signed and the details can be viewed via

$ sqlite3 "$HOME/Library/Application Support/com.apple.TCC/TCC.db"

after granting full disk access to Terminal

$ sqlite3 --box "$HOME/Library/Application Support/com.apple.TCC/TCC.db" 'select * from access where client like "%iterm2%"'

│                service                 │        client         │ client_type │ auth_value │ auth_reason │ auth_version │ csreq │ policy_id │ indirect_object_identifier_type │ indirect_object_identifier │ indirect_object_code_identity │ flags │ last_modified │ pid │ pid_version │ boot_uuid │ last_reminded │
├────────────────────────────────────────┼───────────────────────┼─────────────┼────────────┼─────────────┼──────────────┼───────┼───────────┼─────────────────────────────────┼────────────────────────────┼───────────────────────────────┼───────┼───────────────┼─────┼─────────────┼───────────┼───────────────┤
│ kTCCServiceSystemPolicyDownloadsFolder │ com.googlecode.iterm2 │ 0           │ 2          │ 2           │ 1            │ ��    │           │                                 │ UNUSED                     │                               │ 0     │ 1744937330    │     │             │ UNUSED    │ 0             │
│ kTCCServiceSystemPolicyDocumentsFolder │ com.googlecode.iterm2 │ 0           │ 2          │ 2           │ 1            │ ��    │           │                                 │ UNUSED                     │                               │ 0     │ 1754199221    │     │             │ UNUSED    │ 0             │
└────────────────────────────────────────┴───────────────────────┴─────────────┴────────────┴─────────────┴──────────────┴───────┴───────────┴─────────────────────────────────┴────────────────────────────┴───────────────────────────────┴───────┴───────────────┴─────┴─────────────┴───────────┴───────────────┘```
#13

That’s a good idea, I’d love to take a look.

@bnhf, is this something that OliveTin could help with?

#14

I would think so. The E-Mail Log Alerts Action already does this. It's just a question of having the right pattern or patterns to search for:

screenshot-htpc6-2025-08-24-17-27-15
screenshot-htpc6-2025-08-24-17-27-151015×576 62.7 KB

1 Like
#15

Here is one pattern for people to try if interested. You may find some false positives though, where an email is sent but channels recovered gracefully after a retry

tail -F "$LOGFILE" |
grep --line-buffered "no such file or directory" |

@Fofer So in olive tin, you could try experimenting with the term "no such file or directory" as a search term

I haven't tried the cool email feature in olive tin yet.

#16

Ah, thanks for that. Any idea what the error log would say when channels-dvr can't "find devices on local networks?" I'll keep an eye out on my system, certainly the next time this happens.

#17

I don’t recall parsing the logs and seeing that specific term. The best I could do at the time that I set my email notification script up was to indirectly infer that the drive became unmounted or unavailable by the no such file or directory term.

The drawback is that there can be falls positives if for instance you move some of your personal media around or even rename you personal local media that you had previously imported into channels.

Let’s keep refining these search terms and scripts.
Now that I know that these pop ups are occurring during point updates of macOS I’ll try and take another look at the logs next time I get the pop ups and look for more specific error patterns for my custom scripts and for olivetin.

I’m in the middle of some code development at the moment. Once that is stable I’ll do another MacOs point release and I’m pretty sure I’ll see the pops again

#18

Shouldn't CDVR report its status via some endpoint like /health ? This would make monitoring easy.

#19

I posted a question to the forum some time ago asking if there was any benefit to moving from MacOS 14 to 15 on my M1 Mac mini DVR server. Most of the responses were "scolds" for not mindlessly upgrading with zero reasoning put forth. It appears there IS a benefit to not using MacOS 15 for your server OS at this point.

#20

Nope, apparently not a sym link on MacOS.
Screenshot 2025-08-30 at 10.54.36 AM

#21

Try
ls -l ~Library/Application\ Support/ChannelsDVR

does it show as a link

lrwxrwxrwx+ 1 root  root    15 Aug 23 11:19 latest -> 2025.08.21.1637
^
l means link, d would be directory

Also try stat ~Library/Application\ Support/ChannelsDVR/latest

stat /volume1/docker/channels-dvr-8089/latest
  File: /volume1/docker/channels-dvr-8089/latest -> 2025.08.28.2100
  Size: 15              Blocks: 0          IO Block: 4096   symbolic link
Device: f901h/63745d    Inode: 104628268   Links: 1
Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2025-08-29 21:04:21.635446359 -0700
Modify: 2025-08-28 20:06:07.790632961 -0700
Change: 2025-08-28 20:06:07.790632961 -0700
 Birth: -
#22

Sounds like the dot releases may also affect the network privacy settings

#24

Nope, on MacOS it's a directory

ls -l ~/Library/Application\ Support/ChannelsDVR
total 16
drwxr-xr-x@ 23 doug staff 736 Aug 31 07:32 data
-rwxr-xr-x@ 1 doug staff 2840 Dec 16 2024 install.sh
drwxr-xr-x@ 9 doug staff 288 Aug 24 13:56 latest
-rwxr-xr-x@ 1 doug staff 774 Dec 16 2024 uninstall.sh

1 Like
#25

Well, here's some good news. I've updated quite a few pre-releases of CDVR server since I started this thread, and also a few point releases of macOS Sequoia on this Mac mini, and I have NOT encountered these two Privacy & Security pop-ups again. There were pretty frequent a few months back, very noticeable, and at least twice, it proved to be a literal showstopper. And now, I'm not seeing them at all, despite doing manual updates regularly and sometimes remotely, just as before.

I even upgraded my Mac mini to macOS 26 Tahoe, then to 26.0.1, and the Channels DVR server is still launching automatically without any additional or unexpected pop-ups after restarts or reboots. So I think that was just an unfortunate bug with some earlier versions of Sequoia, an aberration perhaps? Fingers crossed that it's a thing of the past!

Felt like the tables had turned for awhile:

3 Likes