Runtime error using docker compose

[Pietjuhbel]

I saw the other issue being closed where the following problem was also described.

On a completely fresh install of lightNVR using docker compose, myself and other users are greeted with the following errors:
2026-03-18 20:47:34ERRORgo2rtc API client not initialized
2026-03-18 20:47:27ERRORgo2rtc API client not initialized
2026-03-18 20:47:22ERRORAuthentication failed for GET /api/streams request
2026-03-18 20:44:54ERRORLog level set to 2 (INFO)
2026-03-18 20:44:54ERRORFailed to create go2rtc config directory: "/etc/lightnvr/go2rtc"
2026-03-18 20:44:54ERRORFailed to initialize go2rtc process manager
2026-03-18 20:44:54ERRORFailed to initialize go2rtc stream module
2026-03-18 20:44:54ERRORFailed to start go2rtc integration.
2026-03-18 20:44:54ERROREnsure go2rtc is installed and accessible (scripts/install_go2rtc.sh).
2026-03-18 20:44:54ERRORLiveView and WebRTC streaming will not be available until go2rtc is properly configured.

This issue did not exist in earlier builds.

[matteius]

I believe you will have to debug this as I am unable to reproduce and have limited time to work for free.

[DevlTz]

Hi, @matteius! Just trying to give a shot at debugging this one... :P

After reviewing the docker-entrypoint.sh, I found that the script already
does mkdir -p /etc/lightnvr/go2rtc, which is correct. However, the issue
is that right after creating the directory, it runs:

chmod -R 755 /etc/lightnvr

But there's no chown to ensure the directory belongs to the correct user.
When using a bind mount, the host directory typically belongs to UID 1000,
but the container creates subdirectories as root. When LightNVR then tries
to write inside /etc/lightnvr/go2rtc as a non-root process, it gets
permission denied.

Suggested fix in docker-entrypoint.sh, right after the mkdir:

mkdir -p /etc/lightnvr/go2rtc
chown -R $(id -u):$(id -g) /etc/lightnvr/go2rtc
chmod -R 755 /etc/lightnvr/go2rtc

This ensures the directory ownership matches the process running inside
the container, regardless of the host OS or volume mount type.

Note: the :Z flag workaround only helps on SELinux-based systems
(RHEL, Fedora). On Ubuntu/Debian with AppArmor, it has no effect —
which is why users on Ubuntu keep hitting this even after adding :Z.

[Pietjuhbel]

@DevlTz
Nice find this is very helpful!
It completely explains why myself and some other users are experiencing this issue.
I am really looking forward to seeing it being implemented.

@matteius
I absolutely see that you don't have the spare time to investigate these edge cases, I just reposted this issue for others to see it and maybe chip in, in order to find the root cause.

[matteius]

No worries @Pietjuhbel -- sorry for the trouble -- I'll get the compopse file fixed, I closed the prior issue because I felt it was becoming stale but I will not object to re-opening or new issue reports. I also took over maintaing pipenv 4 years ago and there the backlog was so cluttered there are still 100 issues open over 1-5+ years old and so I aim to prevent that here. The goal is of course solving issues, but when I don't have enough information it becomes just a hanging chad. I hope you understand.