[SOLVED]miniDLNA permission issue

I want to be able to run miniDLNA as a separate user. I know how to setup a new user and all that, but since miniDLNA is a daemon that I could put in the DAEMONS array it will still run as root. What other way would I be able to run it under its own separate user??

Also (and I guess, this is related to the above), if I change the media directory from /opt to /home/inxsible/media I get this error

Re: [SOLVED]miniDLNA permission issue

I must admit that my media-folders also are chmod'ed to 777 and that's probably why I don't have the problem. It's on my todo-list to do this correctly with ACL's but right now I don't have the time to do this properly... Sorry.

Now, if I chmod the media-dir to something more secure, let's say '0750', minidlna complains that user 'nobody' has no access to my media (GOOD!). Changing the user in /etc/conf.d/minidlna to 'vincent' makes minidlna complain that there is no group 'vincent:vincent', but there are no permission-errors (GOOD!).

I have not checked whether minidlna streams the media (I am only testing this over SSH), but I'm afraid I cannot reproduce your problem...

Re: [SOLVED]miniDLNA permission issue

So I gather there is no way to point it to a directory under my username

No. It's possible. And you'll probably want to say, 'D'oh !!' again. I know I did after messing around with this issue for way too long.

Anyway, the 'doh' part is that while the directory, "/home/inxsible/media", probably shows permissions like:

drwxr-xr-x inxsible users

your home folder probably has these permissions:

drwx------ inxsible users

Because the parent folder (your home directory) to your media directory (media), doesn't allow any access from any other user or group, 'minidlna' can't get to your media files despite the latter's more permissive settings.

The solution, of course, is to grant privileges to your home directory ('/home/inxsible/'). For me, I had two immediate issues when I encountered this situation:

1. I did not want to grant the 'nobody' user any additional privileges;2. Even if I added a new, more specific user, I didn't want to have to use the heavy hammer of regular user/group permissions.

So, I ended up doing this:

- Changed the user to 'minidlna' from 'nobody'- Added the user / group, 'minidlna', to the system- Set the ACL for '/home/myusername' to allow minidlna 'r-x' access

Note - since you have already run 'minidlna' prior to the above steps, it is necessary to handle the previously-created folders (and files in the folders, if any) created for the 'db_dir' and 'log_dir' as you have specified in the minidlna configuration file. This is necessary because the directories were likely created with 'nobody' as the owner / group if you followed the Wiki instructions. There are a few ways to take care of this, but to keep me from having to write multiple instructions, the remaining guide assumes you just deleted the 'db_dir' and 'log_dir' and are starting fresh in that regard. The only issue this should cause is that the files contained therein will have to be re-created when 'minidlna' is run for the first time after completing the steps outlined here. If you are concerned about deleting, make backups.

Note - It is a good idea to read through the entire guide before really committing to any of the steps. I make no guarantees about the accuracy of the guide (the process works as described, but whether I got it written down correctly is debatable). So, read with 'sanity-check-mode' fully engaged.

Note - Go ahead and stop 'minidlna' before actually performing any of the steps in this guide.

Step 1 - Changing User

Changing the user is simple. Edit the file, /etc/con.d/minidlna, and change the parameter, MINIDLNA_USER:

Before:

MINIDLNA_USER=nobody

After:

#MINIDLNA_USER=nobody
MINIDLNA_USER=minidlna

Step 2 - Adding User / Group To System

Have a look at the man page for 'useradd', but this is the command + options I used:

That will create both the user and group, 'minidlna', in one go. The only odd thing might be '-k /dev/null'. The '-k' modifies the creation of the home directory (the '-m' option) by specifying the directory from which skeleton files will be obtained. I used '/dev/null' so no skeleton files would be placed in the directory (not sure if that's the usual way to do that or not). Also, I set the 'home' directory to the place where 'minidlna' will store its database and art files (this should be the same place you specified for the 'db_dir' directive in the file, '/etc/minidlna.conf'). Finally, if you did not delete the minidlna 'var/*' directories (the ones created while following the Wiki article, as I noted above), you will get a warning that the 'home' directory already exists and no skeleton files were added (you didn't want any anyway, but you still cannot ignore this as it is possible that either your 'db_dr' or your 'log_dir' still have 'nobody' as owner and group).

Now, since the above command took care of re-creation of the the 'db_var' directory and its ownership, you just need to create the 'log_dir' and set it's ownership (again, be sure the path in the command below is the same as you have set in the 'minidlna.conf' file for the log file directory):

As root:

> mkdir /var/log/minidlna
> chown minidlna:minidlna /var/log/minidlna

Step 3 - Set the ACL for '/home/inxsible' to allow minidlna 'r-x' access

In order for ACL to work properly, the filesystem has to be mounted with the option, 'acl', added to the mount command. Just add it to the end of the desired mount-point's options-list in 'fstab' (separated from the preceding option via a comma), for example:

/dev/sdc8 /home reiserfs defaults,notail,noatime,acl 0 1

You'll need to reboot or remount after doing the above.

Next, run the following:

As root:

> setfacl -m u:minidlna:rx /home/inxsible/

That command will give the user, minidlna, read and execute permissions on the home directory (both 'r' and 'x' are required). To see the effect of the command, running 'ls' should show something similar to the following:

Note - Hopefully, you won't want to or need to remove the acl you added and get back to the above (the original state, that is ... assuming you never added any acls to that directory prior to following these instructions). However, if you must (or if you just want to test the command) simply run:

As root:

> setfacl -b /home/inxsible/

Finally (with acl in place), start 'minidlna' and everything should be good ... no errors ... daemon runs correctly ... updates to media folders are added to the database correctly.

Now I'm just waiting for a reply from someone that actually knows what they're doing that explains how to achieve your goal (our goal) in 20 words or less.------------Final Note:

Using the methods outlined here, to my mind, has advantages over simply running as user, 'inxsible', not only from a security perspective (I could be wrong), but since you have created a user and associated group, you will not get the error:

[BUSY] chown: invalid group: 'inxsible:inxsible'

that zenlord mentioned he received when running as his user (his error noted invalid group, 'vincent:vincent').

-----------------

*** By the way, sorry for the late reply ... just found your thread ... but this still might be useful ***

Re: [SOLVED]miniDLNA permission issue

Just my 2 cents, but I found it easier to have all media files outside of a user(s) home, in a mount point for another partition unrelated to the system. I have minidlna, and an nfs share using that partition so mpd clients could share playlists and media while handheld devices and xbox/ps could access dlna.

Re: [SOLVED]miniDLNA permission issue

Re: [SOLVED]miniDLNA permission issue

zero_one wrote:

Just my 2 cents, but I found it easier to have all media files outside of a user(s) home

<snip>

I don't think I can argue with that. And I've got some similar set-ups.

But in one particular case, I've got an Arch-install that has a nice settled-in feel to it as it's been running pretty much in the same way for quite some time. Also, as a consequence, there are a lot of things (software, hardware, people) that have become dependent upon the current configuration (undo / redo will take quite some time). And rather than change everything to fit 'minidlna', I was determined to fit 'minidlna' to the situation in as unobtrusive manner as possible. For the time being, it works.

It's quite possible now that I conquered this, I'll do exactly as you have suggested, but in a more liesurely manner.

Re: [SOLVED]miniDLNA permission issue

For myself and family, I put the shares on a ntfs partition, which maks all the permissions to none and let the other SO access those files.Thanks to MrWeatherbee for his clarifications, that would eventually kill many troubles to set up the right folder.But I'd like to remember that's likely the samba issue, the shares must have permissions on the branch's folder too.

Re: [SOLVED]miniDLNA permission issue

*UPDATE*

The instructions I posted previously were for running minidlna on a system using 'sysvinit'.

If anyone wants to continue with this method after switching to 'systemd', you'll have to create a custom 'minidlna.service' file since this is now the file that specifies the daemon-user (for 'sysvinit', the user is specified in the '/etc/con.d/minidlna' file).

You will now also have to change '/lib/lib/tmpfiles.d/minidlna.conf' because it sets the permissions for the PID file folder and will set them to nobody:nobody, which will cause minidlna to fail. Here are the contents of my file after the change:

---Note - I originally thought initially starting the daemon using the default service file had set the PID folder permissions to 'nobody' based on the user in that file being set to nobody, so I just changed the folder permissions to 'minidlna' after creating the custom service file, and everything worked fine after restarting 'minidlna'. However, after rebooting, the PID folder permissions were again set to 'nobody:nobody', and that's when I discovered that the culprit was '/lib/lib/tmpfiles.d/minidlna.conf'.

Re: [SOLVED]miniDLNA permission issue

Genius!! Many thanks MrWeatherbee!!!You've answered many of my questions in one post as I'm relatively new to Linux. Sorry to Necrobump but I'm guessing most of this will be transferable to Sabnzbd using systemd

In a similar situation where I don't want to have to reconfigure my whole system for the sake of 2 apps. I've got quite settled with this one

Re: [SOLVED]miniDLNA permission issue

The key for me was giving read and execute permission. The default user is now minidlna, so that part is already done. Also, minidlna does not seem to like symbolic links, so keep that in mind if you run into issues.