ZoneMinder Forums

Hi all!

On the CLI, this works perfectly:

ffplay rtsp://admin:password@192.168.15.100:554/Streaming/channels/101


In the "Source Path" field I have this:

rtsp://admin:password@192.168.15.100:554/Streaming/channels/101

However, the log says this:

Unable to open input rtsp://192.168.15.100/Streaming/channels/101 due to: Permission denied

How can I persuade zoneminder to pass the credentials to the camera?

ZM does pass them. The logs are automatically sanitised.

Are there weird characters in the password?

No.

Does ZM offer any way to debug this, or do I need to fall back to externnal tools like tcpdump?

You can turn on debug logging and it will be very verbose. I can see that this is a Hikvision/clone.. they have a feature that locks you out after a few bad login attempts.
You can check the logs in the camera itself, it might give a clue.

Well I upgraded the firmware in the camera in hope - and now VLC can't load the stream either.

Ah well, thanks anyway guys, but I can't get this thing to talk RTSP to me at all any more.

I tried:

- a new username
- changing to "basic" from digest auth
- A different password

And I did notice - and nobody will believe this - if I put secRet on the vlc bash CLI for the password, wireshark shows that secret was sent as the password, changing R to r.

The camera won't accept a password without upper case.

Work continues.

Packet capture shows that the zoneminder server never makes an outbound connection to the remote camera.

my use of VLC or telnet to 554 is shown by 'tcpdump host xxx.yyy.zzz.www' but ZoneMinder happily throws permission denied errors without sending any bytes over the network.

What permission is being denied? Filesystem? Database?

anotheruser wrote: ↑Sat Jun 07, 2025 1:15 am if I put secRet on the vlc bash CLI for the password, wireshark shows that secret was sent as the password, changing R to r.

That is a ridiculous level of broken. Moreso than apps that get confused by $ and % in passwords .... (and they do exist, even my former ISP had a POP3/Mail l interface which rejected my password. "By default it is the same as your dialup password". OK. Not working. This is because my dialup password had a '%' in it (upper, lower, numbers, punctuation). And that worked fine, but wouldn't work on POP3 server. Dumb dumb dumb.

To change a password "in flight" is very bad behaviour!

As to "permission denied" -- if you are not seeing an outbound connection at the TCP/UDP level, it makes me think that some 'helper app' that ZM is calling on is failing to run. "Permission Denied" feels Unix-permissions related, couldn't execute a script, script starts with "!/bin/oopsy" which doesn't exist so the _script_ reports as 'permission denied' when the error is the underlying interpreter, a config file is unreadable (being read by www . data, owned by root.root ... ?) and you may have to use 'strace' on ZM or parts of ZM to see what is raising the error. Output will be voluminous, so redirect to a file and grep through it for 'Permission' ...

Don't know the mechanics of how ZM deals with "rtsp://" protocol -- e.g. a streaming executable, a library, etc. ??

Alright.

So vlc on windows prompts the user for credentials, and works.

Arch with Gui fails, Rocky with no gui (cvlc) fails, ubuntu with cvlc fails. Turns out LOTS of people find that VLC 3.0.21 can't handle rtsp auth properly; so VLC wasn't an appropriate "test suite", and was a red herring for whatever ZM was having problems with.

Rocky is gone now, and zoneminder along with it.

ffmpeg works perfectly in Ubunutu.

I understand what you're saying and maybe I could have got there if the log presented the output returned by the commands "lower in the stack".

I couldn't get ONVIF to do anything in ZM either.

I like zm, I tried to get it working years ago and failed then too.

I've moved on to "motion" and maybe that will be easier.