#64 warn on files.db ownership/permissions mismatch

[Royce Williams]

For future troubleshooters:

This symptom can sometimes be cause by a permissions mismatch. During other troubleshooting, I ran minidlna -R as root, after which the daemon (running as user 'minidlna' on my FreeBSD system) couldn't read the file.

[Royce Williams]

Apologies; I thought I was leaving a comment. However, this could very well be a feature request: for MiniDLNA to detect and give an explicit error in the case of a permissions mismatch.

[Royce Williams]

This feature request was inspired by #2857214.

[Joe]

I know this is an old one, but I've created a patch against 1.1.1
Basically it chmods the db_path to the uid that minidlna runs as.
If it can't do it, then it gives a fatal error.

Otherwise, warnings concerning the db are pretty well formed.

[Royce Williams]

Always a pleasant surprise when an old ticket is resurrected! Thanks very
much!
On Feb 27, 2014 11:16 AM, "Joe" finitelife@users.sf.net wrote:

I know this is an old one, but I've created a patch against 1.1.1
Basically it chmods the db_path to the uid that minidlna runs as.
If it can't do it, then it gives a fatal error.

Otherwise, warnings concerning the db are pretty well formed.

Attachment: db_own.diff (557 Bytes; application/octet-stream)

• [feature-requests:#64]
  http://sourceforge.net/p/minidlna/feature-requests/64/ warn on files.db
  ownership/permissions mismatch*

Status: open
Created: Fri Feb 17, 2012 06:09 AM UTC by Royce Williams
Last Updated: Fri Feb 17, 2012 06:20 AM UTC
Owner: nobody

For future troubleshooters:

This symptom can sometimes be cause by a permissions mismatch. During
other troubleshooting, I ran minidlna -R as root, after which the daemon
(running as user 'minidlna' on my FreeBSD system) couldn't read the file.

---

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/minidlna/feature-requests/64/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

[Justin Maggard]

I checked in something similar. I think fatal is a bit too harsh, since the directory could be writeable by the configured user, even if he doesn't own it, so there will just be an error logged.