minidlna update no longer access media files

[mcloaked]

I updated my cubox system a short time ago and now I am getting a permissions error for minidlna

$this->bbcode_second_pass_code('', '
# systemctl -l status minidlna
* minidlna.service - minidlna server
Loaded: loaded (/usr/lib/systemd/system/minidlna.service; disabled; vendor preset: disabled)
Active: active (running) since Thu 2015-02-26 21:47:05 GMT; 2min 15s ago
Main PID: 344 (minidlnad)
CGroup: /system.slice/minidlna.service
`-344 /usr/bin/minidlnad -S

Feb 26 21:47:05 cubox1 systemd[1]: Started minidlna server.
Feb 26 21:47:05 cubox1 minidlnad[344]: [2015/02/26 21:47:05] minidlna.c:611: error: Media directory "A,/home/mike/Music/" not accessible [Permission denied]
Feb 26 21:47:05 cubox1 minidlnad[344]: [2015/02/26 21:47:05] minidlna.c:611: error: Media directory "P,/home/mike/Pictures/" not accessible [Permission denied]
Feb 26 21:47:05 cubox1 minidlnad[344]: [2015/02/26 21:47:05] minidlna.c:611: error: Media directory "V,/home/mike/Videos/" not accessible [Permission denied]
Feb 26 21:47:05 cubox1 minidlnad[344]: minidlna.c:1026: warn: Starting MiniDLNA version 1.1.4.
Feb 26 21:47:05 cubox1 minidlnad[344]: minidlna.c:1065: warn: HTTP listening on port 8200
')

The directories are world readable:

# ls -l /home/mike/
total 12
drwxrwxrwx 3 mike mike 4096 Aug 20 2014 Music
drwxrwxrwx 3 mike mike 4096 Oct 3 2001 Pictures
drwxrwxrwx 9 mike mike 4096 Nov 28 09:28 Videos

I deleted the /var/cache/minidlna subdirectories and restarted minidlna but this still does not seem to work. The ownership of /var/cache/minidlna is minidlna:minidlna

Can anyone suggest how to get minidlna working again?

[pepedog]

Are you running as Mike?
To do that
systemctl edit minidlna
Now don't do this literal, look at /usr/lib/systemd/system/minidlna.service for actual content
Put this into edit
[Service]
User = mike
Group = mike

[mcloaked]

I tried that as well as cleaning out the cache directory to let minidlna rebuild it but it still failed. I have also tried setting user to nobody in /etc/minidlna.conf which also failed.

Is there any need in the new version to have media directories owned not by a user (such as mike)? Or to symlink media directories to links owned by minidlna?

In /etc/minidlna.conf the user is minidlna now as per the new pacnew file after the update today.

[mcloaked]

For the moment I have downgraded to minidlna 1.1.4-3 and in /etc/minidlna.conf set the user to nobody and it works fine again.

I will research this more and see if I can find why version 1.1.4-5 fails to work with my setup.

[jass0]

Hi,

The breaking changes originate from this:
https://bugs.archlinux.org/task/43681

1.1.4-3 systemd service started as "root"
1.1.4-4 systemd service started as "nobody"
1.1.4-5 systemd service started as "minidlna"

I think these directories need to be accessible by both the service initiator and the user defined in minidlna.conf:

/var/run/minidlna
/var/cache/minidlna


This is how my setup currently works in 1.1.4-5:
In minidlna.conf I have "user minidlna"
/var/run/minidlna and /var/cache/minidlna chowned by minidlna:minidlna
(and all my media accessible by minidlna)

I hope this helps.

[mcloaked]

I worked some more on this, and after updating to the latest version again, I removed the file /var/cache/minidlna/* and made sure that the /var/cache/minidlna directory was chowned to minidlna:minidlna as I had done previously. Since the problem seemed to be associated with permissions on the media directories and files I made a new directory /opt/Local/Videos which was chowned to minidlna:minidlna and then placed mp4 files in that directory also chowned to the same ownership. The /etc/minidlna.conf file was edited to start the daemon as user minidlna and the media files directory was pointed to the new directory made above. Then on restarting the minidlna daemon, it starts up correctly, and there are no permissions errors, and the server works perfectly well.

In order to test the permissions problem I changed the media directory /opt/Local/Videos to be a symlink to my own directory at /home/mike/Videos that has permissions 777 and is world readable. On cleaning up minidlna and restarting the daemon the same permissions errors occur, and the server is unable to read or serve the video files. I also ran a test specifying the media directory in /home/mike/Videos which of course is owned by user mike and the same permission errors occur despite the directory and files being world readable. I also did a test chowning /home/mike/Vidoes to minidlna:mindlna and that gives permissions errors also. So there is clearly a much stricter limitation on the media directory permissions and ownership now than in the previous version.

So I have my system working but only by making the media directories owned by user minidlna as well as their contents and I would very much like to know if there is a specific requirement for setting up the media directories when they are owned by a different user to minidlna when minidlna itself is running as user minidlna? Is there a requirement on the ownership and permissions of directories above those defining the media directories in /etc/minidlna.conf as well as the permissions and ownership of the files themselves?

I would be interested to know how others have made this work on their systems with the new version minidlna 1.1.4-5 particularly on defining the user running minidlna as well as how the media directories have been set up? If the user running the daemon is minidlna then how to set up media directories and files owned by a normal user?

[pepedog]

What happens if you comment out user= in minidlna.conf (also PrivateDevices=off) and have .service set as user mike

[JamesBingo]

As jass0 said the breaking changes in https://bugs.archlinux.org/task/43681 modify the service file to enable the ProtectHome option, this has the effect of making the /home directory inaccessible.

Your media files are stored in a subdirectory of home and therefore minidlna can't read them.

You can change the minidlna service file ProtectHome option to 'read-only', this will then grant the minidlna daemon read access to your media files inside your /home/mike/Videos directory or alternatively you can move them outside of home (which you did succesfully).

[mcloaked]

OK I finally got this working satisfactorily and I will detail the changes I made so that others can benefit from my struggle with it.

Firstly I thought I would try to get the server to run as user mike. I did try to change the line in the service file to have ProtectHome=read-only but when the daemon was running as user minidlna this still gave the same permissions errors when the media files were set to be directories in the /home area for user mike.

So after a number of changes the set of changes that finally worked for me is as follows:

The systemd unit file at /usr/lib/systemd/system/minidlna.service now contains the following:

$this->bbcode_second_pass_code('', '
[Unit]
Description=minidlna server
After=network.target

[Service]
Type=simple
User=mike
Group=mike
ExecStart=/usr/bin/minidlnad -S
ProtectSystem=full
ProtectHome=read-only
PrivateDevices=on
NoNewPrivileges=on

[Install]
WantedBy=multi-user.target
')

So this was set to run the daemon as user mike and also to change the default ProtectHome from "on" to "read-only" which is the suggestion for this parameter in the systemd directives descriptor at http://www.freedesktop.org/software/sys ... .exec.html

Secondly I changed the /etc/minidlna.conf file to have the user specified as "mike", and the media files within mike's /home/mike area and have read access to all.

So in /etc/minidlna,conf I have user=mike and also:

$this->bbcode_second_pass_code('', '
media_dir=A,/home/mike/Music/
media_dir=P,/home/mike/Pictures/
media_dir=V,/home/mike/Videos/
')

I also changed the log file definition to:

$this->bbcode_second_pass_code('', '
log_dir=/home/mike/.config/minidlna
')

Note that I did try to also change the db_dir=/home/mike/.config/cache/minidlna but that led to a failure to start the systemd unit so I reverted that line to:

$this->bbcode_second_pass_code('', '
db_dir=/var/cache/minidlna
')

Then I made sure that the ownership and permissions for the various key directories and files were set as:

$this->bbcode_second_pass_code('', '
[root@cubox1 ~]# ls -ld /var/cache/minidlna
drwxr-xr-x 3 mike mike 4096 Feb 27 15:12 /var/cache/minidlna
[root@cubox1 ~]# ls -l /var/cache/minidlna
total 716
drwxr-xr-x 3 mike mike 4096 Feb 27 15:12 art_cache
-rw-r--r-- 1 mike mike 729088 Feb 27 15:12 files.db
')

The pid file has permissions:

$this->bbcode_second_pass_code('', '
[root@cubox1 ~]# ls -ld /var/run/minidlna
drwxr-xr-x 2 mike mike 60 Feb 27 15:06 /var/run/minidlna
[root@cubox1 ~]# ls -l /var/run/minidlna
total 4
-rw-r--r-- 1 mike mike 6 Feb 27 15:12 minidlna.pid
')

Now restarting the daemon (after doing systemctl daemon-reload) now gives a correctly started minidlna daemon:

$this->bbcode_second_pass_code('', '
[root@cubox1 ~]# systemctl -l status minidlna
* minidlna.service - minidlna server
Loaded: loaded (/usr/lib/systemd/system/minidlna.service; disabled; vendor preset: disabled)
Active: active (running) since Fri 2015-02-27 15:24:59 GMT; 1s ago
Main PID: 15805 (minidlnad)
CGroup: /system.slice/minidlna.service
`-15805 /usr/bin/minidlnad -S

Feb 27 15:24:59 cubox1 systemd[1]: Started minidlna server.
Feb 27 15:24:59 cubox1 minidlnad[15805]: minidlna.c:1026: warn: Starting MiniDLNA version 1.1.4.
Feb 27 15:24:59 cubox1 minidlnad[15805]: minidlna.c:1065: warn: HTTP listening on port 8200
')

Initially when I restarted the daemon with a cleaned out cache area then there were additional messages confirming that the database was being recreated:

$this->bbcode_second_pass_code('', '
Feb 27 15:12:03 cubox1 systemd[1]: Started minidlna server.
Feb 27 15:12:03 cubox1 minidlnad[15782]: minidlna.c:1026: warn: Starting MiniDLNA version 1.1.4.
Feb 27 15:12:03 cubox1 minidlnad[15782]: minidlna.c:355: warn: Creating new database at /var/cache/minidlna/files.db
Feb 27 15:12:03 cubox1 minidlnad[15782]: minidlna.c:1065: warn: HTTP listening on port 8200
Feb 27 15:12:44 cubox1 minidlnad[15782]: playlist.c:125: warn: Parsing playlists...
Feb 27 15:12:44 cubox1 minidlnad[15782]: playlist.c:259: warn: Finished parsing playlists.
')

So finally this is working but there are clearly watchpoints along the way and it is necessary to pay attention to the systemd unit file contents, as well as the contents of the /etc/minidlna.conf file and also the ownership of the pid file directory and the cache directory.

Once all of that is done then it works - apart from so far not having any entries in the log file at /home/mike/.config/minidlna/minidlna.log

[mcloaked]

I also made a directory outside of /home (which is now read-only in the systemd unit file) at /opt/Local/minidlna/ and hoped that redefining the log directory in /etc/minidlna.conf to specify that directory would allow writing the logfile, but that does not work - so I still don't understand this aspect of the changes.

One other thing that I have noticed is that every time I restart the daemon I am seeing messages like this in the journal:

$this->bbcode_second_pass_code('', '
Feb 27 16:01:58 cubox1 systemd[1]: Starting minidlna server...
Feb 27 16:01:58 cubox1 systemd[1]: Failed to set memory.limit_in_bytes on : Invalid argument
Feb 27 16:01:58 cubox1 systemd[1]: Failed to reset devices.list on /system.slice: Invalid argumen
Feb 27 16:01:58 cubox1 systemd[1]: Started minidlna server.
Feb 27 16:01:58 cubox1 systemd[1]: Failed to reset devices.list on /user.slice: Invalid argument
')

I don't know if this is a consequence of the new version or something else unrelated?

Also @pepedog I tried your suggestion of doing PrivateDevices=off (thank you), but that did not prevent the problems that I had.

I was also unsure whether the top of the linked arch flyspray bug report might suggest that running the systemd unit as user nobody might allow the log files to be written, but presumably this would then require associated changes for ownership in the various other files that I listed in my previous post? So perhaps changing over to running as user nobody for the systemd unit as well as specifying user=nobody in /etc/minidlna.conf as well as changing ownership of the pid file, cache and log files to user nobody would then allow the minidlna server to work with media files in user mike's area, and also generate entries in /var/log/minidlna.log ? However I also noted from a bug report that running as user nobody is advised against - see the closed bug at https://bugs.archlinux.org/task/43964