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
[inxsible ~ ]$ start minidlna :: Starting minidlna [BUSY] [2012/07/15 23:44:51] minidlna.c:472: error: Media directory "/home/inxsible/media" not accessible! [Permission denied] [DONE] [inxsible ~ ]$
since it started as root, shouldn't the folder be accessible?
iirc, you can set the $MINIDLNA_USER-var inside /etc/conf.d/
Default is user "nobody", btw.
Default is user "nobody", btw.
D'oh !! that explains the latter part of my op.
zenlord, I will try it out tonight and update. Thanks !
so I am sticking with starting minidlna with the user "nobody". However, the permission problem persists. I even chmodded the /home/inxsible/media to 777 but it still gives me the same error.
What am I missing?
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.
OK, plenty of time to sleep when I'm dead
I changed the username in /etc/conf.d/minidlna to 'vincent' and I got the following output:
# /etc/rc.d/minidlna restart :: Stopping minidlna [DONE] :: Starting minidlna [BUSY] chown: invalid group: 'vincent:vincent' [DONE]
Specifying the group is not an option.
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...
HTH though. Maybe try reinstalling minidlna?
after further testing, here are the results
Changed the minidlna user in /etc/conf.d/minidlna -- Gives me the same invalid group error. My TV lists the files, but no matter what format they are I get an error
The file format is currently not supported
back to default "nobody" & media_dir=/home/inxsible/media -- I get a permission denied error as in my first post -- TV giveo this error
No video files found on the connected device
user=nobody & media_dir=/opt -- Everything works
So I gather there is no way to point it to a directory under my username
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:
Step 2 - Adding User / Group To System
Have a look at the man page for 'useradd', but this is the command + options I used:
useradd -U -m -k /dev/null -d /var/cache/minidlna -s /bin/false minidlna
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):
> 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:
> 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:
drwxr-x---+ inxsible users
Taking advantage of the acl tools, run the command:
> getfacl /home/inxsible/
which should show you something like this:
getfacl: Removing leading '/' from absolute path names # file: home/inxsible/ # owner: inxsible # group: users user::rwx user:minidlna:r-x group::--- mask::r-x other::---
By the way, this is what that command would output prior to setting any 'custom' acl's:
getfacl: Removing leading '/' from absolute path names # file: home/inxsible/ # owner: inxsible # group: users user::rwx group::--- other::---
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:
> 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.
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 ***
Last edited by MrWeatherbee (2012-08-26 11:50:23)
Thanks MrWeatherbee. I'll try this out tonight as I still keep moving things to /opt for streaming. Will let you know how it goes.
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.
Last edited by zero_one (2012-08-28 16:34:07)
You're welcome and good luck.
Just my 2 cents, but I found it easier to have all media files outside of a user(s) home
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.
but in a more liesurely manner.
Thats the only way to fly. I'm to the point where I'm now rsync'ing my gmpc cache across multiple users on 5 machines, all clients have artwork and lyrics from network shares.
Sorry to veer off topic X.
Last edited by zero_one (2012-08-28 23:41:52)
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
In fact, I think the /srv/media/-folder is the right place to put media files if they are being shared through whatever protocol.
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.
do it good first, it will be faster than do it twice the saint
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).
For systemd, simply change the minidlna.service file contents from:
[Unit] Description=minidlna server After=network.target [Service] Type=forking User=nobody ExecStart=/usr/sbin/minidlna -P /var/run/minidlna/minidlna.pid PIDFile=/var/run/minidlna/minidlna.pid [Install] WantedBy=multi-user.target
[Unit] Description=minidlna server After=network.target [Service] Type=forking User=minidlna ExecStart=/usr/sbin/minidlna -P /var/run/minidlna/minidlna.pid PIDFile=/var/run/minidlna/minidlna.pid [Install] WantedBy=multi-user.target
You should be able to make this work following the service file override instructions in the wiki (I used the entire contents of the file ... I did not use the alternate '.include' method):
https://wiki.archlinux.org/index.php/Sy … unit_files
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:
# systemd tmpfile settings for minidlna # See tmpfiles.d(5) for details #d /var/run/minidlna 0755 nobody nobody - d /var/run/minidlna 0755 minidlna minidlna -
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'.
Last edited by MrWeatherbee (2012-11-04 02:46:21)
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
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.
"Melody reigns supreme!"
-J. J. Johnson
HarlemSquirrel, you have been around long enough to know not to necrobump. Please don't do it.
Mobo: ASUS P8Z77-V PRO // Processor: Intel Core i7-3770K 3.4GHz // GFX: nVidia GeForce GTX 970 Ti // RAM: 32GB (4x 8GB) Corsair DDR3 (@ 2133MHz) // Storage: 1x 3TB Seagate SATAII 5x 1TB Samsung SATAII, 2x 120GB Corsair SSD
Making lemonade from lemons since 2015.