minidlna fixed didn't work for me but I figured out that FLAC library also needed update.

[Kevin Roberts]

Greetings!

Just a heads up. I've updated to RC4 from RC3 and hadn't been able to get minidlna or forked daapd to run since.

I receive the known error message with minidlna but for the library libFLAC,so.8 so I tried the fix listed elsewhere. As follows.

login as: root

ro...@192.168.1.109's password:

COLUMNS=80;LINES=24;export COLUMNS LINES;

[root@DNS-323]# ls -l /usr/lib/libjpeg.so*

lrwxrwxrwx    1 root     root            16 Jun 29 11:41 /usr/lib/libjpeg.so -> libjpeg.so.8.3.0

lrwxrwxrwx    1 root     root            16 Jun 29 11:41 /usr/lib/libjpeg.so.8 -> libjpeg.so.8.3.0

-rwxr-xr-x    1 root     root        223776 Jun 24 09:27 /usr/lib/libjpeg.so.8.3.0

[root@DNS-323]# ls -l /usr/lib/libsqlite3.so*

lrwxrwxrwx    1 root     root            19 Jun 29 11:42 /usr/lib/libsqlite3.so -> libsqlite3.so.0.8.6

lrwxrwxrwx    1 root     root            19 Jun 29 11:42 /usr/lib/libsqlite3.so.0 -> libsqlite3.so.0.8.6

-rwxr-xr-x    1 root     root        657140 Jun 24 09:27 /usr/lib/libsqlite3.so.0.8.6

[root@DNS-323]# ipkg -force-reinstall install jpeg-libs

Reinstalling jpeg-libs (8c-3) on /Alt-F...

Downloading http://sourceforge.net/projects/alt-f/files/pkgs/unstable/jpeg-libs_8c-3_arm.ipk

Configuring jpeg-libs

Successfully terminated.

[root@DNS-323]# ipkg -force-reinstall install sqlite-libs

Reinstalling sqlite-libs (3080200) on /Alt-F...

Downloading http://sourceforge.net/projects/alt-f/files/pkgs/unstable/sqlite-libs_3080200_arm.ipk

Configuring sqlite-libs

Successfully terminated.

[root@DNS-323]#

The reinstalls appear to complete but I still get the same error message. Looks like I need to update another/different library?

forked daapd error message only says that it failed like this: starting forked daapd: fail.

Tried:

ipkg -force-reinstall install flac-libs

and that did the trick for both. So you might want to make an additional note about updating that library also.

So to confirm forked daapd and minidlna required me to update the flac library before they would work.

[João Cardoso]

I have changed the README in the download area to enforce that all services must be stopped before updating all packages.

The normal install script for packages that have an initscript is to stop the service before doing the update, but this does not covers the situation when the package contains a library that might be in use by other services.

This means that even updating a single library package might fail when that library is in use by a running process.

Unfortunately 'ipkg' is not clever enough to determine that a file (library or executable) that is in use might miss the update.

Meanwhile, the naive script shown bellow checks all packages for missing files.

Just save it in the box, e.g., under the name 'check-pkgs.sh', set it as executable, 'chmod +x check-pkgs.sh', and execute it, './check-pkgs.sh'.

On my system it reports:

package bzip2: missing file /Alt-F/usr/bin/bzcat

package bzip2: missing file /Alt-F/usr/bin/bunzip2

package python: missing file /Alt-F/usr/lib/python2.7/Makefile

package python: missing file /Alt-F/usr/lib/python2.7/pyconfig.h

but that is my fault, don't worry. I have to more deeply investigate that.

Thanks

#!/bin/sh

for j in $(ipkg -V0 list_installed | cut -d" " -f1); do

    for i in $(ipkg -V0 files $j | grep ^/Alt-F); do

        if ! readlink -f $i >/dev/null ; then

            echo package $j: missing file $i  

        fi 

    done 

done

[Kevin Roberts]

Greetings!

As a Noob, I've not yet gotten the script to run. I copied it to a text file (under Windows) and saved it as  check-pkgs.sh. I copied the script file to the DNS-323 B1 Volume_2 root and telenet in with putty as follows:

login as: root

ro...@192.168.1.109's password:

COLUMNS=80;LINES=24;export COLUMNS LINES;

[root@DNS-323]# cd /mnt/Volume_2

[root@DNS-323]# chmod +x check-pkgs.sh

[root@DNS-323]# ./check-pkgs.sh

-sh: ./check-pkgs.sh: not found

[root@DNS-323]# /mnt/Volume_2/check-pkgs.sh

-sh: /mnt/Volume_2/check-pkgs.sh: not found

[root@DNS-323]#

Chmod seems to execute okay? Not sure why it's not found?

I also note that forked daapd is shutting down on it's own. I start it and it seems to be doing a media scan but when I check later it's stopped on it's own. I have a large mp3 library of over 17000 tracks.

(fifth attempt to post this reply)

[João Cardoso]

On Tuesday, July 1, 2014 4:45:50 PM UTC+1, Kevin Roberts wrote:

Greetings!

As a Noob, I've not yet gotten the script to run. I copied it to a text file (under Windows)

ahhh, can't do that, it's like English and American :-)

However you can convert text files using the 'dos2unix' and 'unix2dos' commands. In your case you want to use 'dos2unix check-pkgs.sh'

 

and saved it as  check-pkgs.sh. I copied the script file to the DNS-323 B1 Volume_2 root and telenet in with putty as follows:

 ...

[root@DNS-323]# cd /mnt/Volume_2

[root@DNS-323]# chmod +x check-pkgs.sh

[root@DNS-323]# ./check-pkgs.sh

-sh: ./check-pkgs.sh: not found

[root@DNS-323]# /mnt/Volume_2/check-pkgs.sh

-sh: /mnt/Volume_2/check-pkgs.sh: not found

[root@DNS-323]#

Chmod seems to execute okay? Not sure why it's not found?

I also note that forked daapd is shutting down on it's own.

probably it crashed because some "strange" file.

You should find a log under System->Utilities->View Logs

 

I start it and it seems to be doing a media scan but when I check later it's stopped on it's own. I have a large mp3 library of over 17000 tracks.

Start using it on a subset of folders with less files. 

[Kevin Roberts]

Greetings!

I figured it was something like that. Thank you, Teacher João. File converted:

login as: root

ro...@192.168.1.109's password:

COLUMNS=80;LINES=24;export COLUMNS LINES;

[root@DNS-323]# dos2unix check-pkgs.sh

dos2unix: can't open 'check-pkgs.sh': No such file or directory

[root@DNS-323]# cd /mnt/Volume_2

[root@DNS-323]# dos2unix check-pkgs.sh

[root@DNS-323]# chmod +x check-pkgs.sh

[root@DNS-323]# ./check-pkgs.sh

package avahi: missing file /Alt-F/etc/avahi/services/rsync.service-

package avahi: missing file /Alt-F/etc/avahi/services/printer.service-

package avahi: missing file /Alt-F/etc/avahi/services/http.service-

package avahi: missing file /Alt-F/etc/avahi/services/ssh.service-

package avahi: missing file /Alt-F/etc/avahi/services/ftp.service-

package avahi: missing file /Alt-F/etc/avahi/services/smb.service-

package avahi: missing file /Alt-F/etc/avahi/services/sftp-ssh.service-

package avahi: missing file /Alt-F/etc/avahi/services/telnet.service-

package bzip2: missing file /Alt-F/usr/bin/bzcat

package bzip2: missing file /Alt-F/usr/bin/bunzip2

package python: missing file /Alt-F/usr/lib/python2.7/Makefile

package python: missing file /Alt-F/usr/lib/python2.7/pyconfig.h

package vsftpd: missing file /Alt-F/etc/vsftpd.conf

[root@DNS-323]#

Looks like AVAHI is pretty hosed. I expect that could be the root of my problems.

Because of the dependencies with forked_daapd and mpd I can't remove it without removing those. What is your suggestion on how I should proceed? Should I nuke all three and start over?

[João Cardoso]

On Wednesday, July 2, 2014 3:10:12 PM UTC+1, Kevin Roberts wrote:

Greetings!

I figured it was something like that. Thank you, Teacher João. File converted:

login as: root

COLUMNS=80;LINES=24;export COLUMNS LINES;

[root@DNS-323]# dos2unix check-pkgs.sh

dos2unix: can't open 'check-pkgs.sh': No such file or directory

[root@DNS-323]# cd /mnt/Volume_2

[root@DNS-323]# dos2unix check-pkgs.sh

[root@DNS-323]# chmod +x check-pkgs.sh

[root@DNS-323]# ./check-pkgs.sh

package avahi: missing file /Alt-F/etc/avahi/services/rsync.service-

package avahi: missing file /Alt-F/etc/avahi/services/printer.service-

package avahi: missing file /Alt-F/etc/avahi/services/http.service-

package avahi: missing file /Alt-F/etc/avahi/services/ssh.service-

package avahi: missing file /Alt-F/etc/avahi/services/ftp.service-

package avahi: missing file /Alt-F/etc/avahi/services/smb.service-

package avahi: missing file /Alt-F/etc/avahi/services/sftp-ssh.service-

package avahi: missing file /Alt-F/etc/avahi/services/telnet.service-

package bzip2: missing file /Alt-F/usr/bin/bzcat

package bzip2: missing file /Alt-F/usr/bin/bunzip2

package python: missing file /Alt-F/usr/lib/python2.7/Makefile

package python: missing file /Alt-F/usr/lib/python2.7/pyconfig.h

package vsftpd: missing file /Alt-F/etc/vsftpd.conf

[root@DNS-323]#

Looks like AVAHI is pretty hosed.

That is OK.

Avahi is shipped with a set of services files services/xx-; when it starts its initscript checks which services are running and available and renames the services files to xx, so avahi will advertise the services. So everything is OK

 

I expect that could be the root of my problems.

Because of the dependencies with forked_daapd and mpd I can't remove it without removing those. What is your suggestion on how I should proceed? Should I nuke all three and start over?

No.

I'm pretty sure that the forked_daapd failure has to do with some media file that makes it crash; only scanning folder by folder or increasing the log verbosity of forked_daapd, see /etc/forked-daapd.conf, will be sure.

And minidlna is working, right?

 

[Kevin Roberts]

After a recent reboot the problem with the forked daapd service stopping has not occurred again. Neither forked daapd or minidlna are working though. Looking at the logs, it looks like a permission problem remains.

[2014/07/08 11:23:37] minidlna.c:1014: warn: Starting MiniDLNA version 1.1.3.
[2014/07/08 11:23:37] minidlna.c:355: warn: Creating new database at /var/lib/minidlna/files.db
[2014/07/08 11:23:38] minidlna.c:1053: warn: HTTP listening on port 8200
[2014/07/08 11:23:38] scanner.c:736: warn: Error scanning /mnt/Volume_2/Public/RW/My_Videos
[2014/07/08 11:23:38] scanner.c:736: warn: Error scanning /mnt/Volume_2/Public/RW/Pictures
[2014/07/08 11:23:39] scanner.c:736: warn: Error scanning /mnt/Volume_2/Public/RW/My_Music
[2014/07/08 11:23:39] playlist.c:125: warn: Parsing playlists...
[2014/07/08 11:23:39] playlist.c:259: warn: Finished parsing playlists.
[2014/07/08 11:23:40] inotify.c:92: error: inotify_add_watch(/mnt/Volume_2/Public/RW/My_Videos) [Permission denied]
[2014/07/08 11:23:40] inotify.c:92: error: inotify_add_watch(/mnt/Volume_2/Public/RW/Pictures) [Permission denied]
[2014/07/08 11:23:40] inotify.c:92: error: inotify_add_watch(/mnt/Volume_2/Public/RW/My_Music) [Permission denied]
[2014/07/08 11:23:40] inotify.c:92: error: inotify_add_watch(/mnt/Volume_2/Public/RW/My_Videos) [Permission denied]
[2014/07/08 11:23:40] inotify.c:92: error: inotify_add_watch(/mnt/Volume_2/Public/RW/Pictures) [Permission denied]
[2014/07/08 11:23:40] inotify.c:92: error: inotify_add_watch(/mnt/Volume_2/Public/RW/My_Music) [Permission denied]

Looks like I'll have to do some research on configuring the permissions properly. I may need to add daemons to the user group or something like that.

[João Cardoso]

On Tuesday, July 8, 2014 4:29:14 PM UTC+1, Kevin Roberts wrote:

After a recent reboot the problem with the forked daapd service stopping has not occurred again. Neither forked daapd or minidlna are working though. Looking at the logs, it looks like a permission problem remains.

[2014/07/08 11:23:37] minidlna.c:1014: warn: Starting MiniDLNA version 1.1.3.
[2014/07/08 11:23:37] minidlna.c:355: warn: Creating new database at /var/lib/minidlna/files.db
[2014/07/08 11:23:38] minidlna.c:1053: warn: HTTP listening on port 8200
[2014/07/08 11:23:38] scanner.c:736: warn: Error scanning /mnt/Volume_2/Public/RW/My_Videos

minidlna runs (when called through its initscript 'rcminidlna' or through the webUI) as user 'minidlna' and group 'multimedia'.
Just like a normal user it has to have permissions to read files and browse folders in the folders and subfolders that it is going to scan.
The default Public folder has such permissions, don't know what permissions and ownsership Public/RW/My_Videos (and its files and subfolders) have.

[Kevin Roberts]

Greetings!

 

minidlna runs (when called through its initscript 'rcminidlna' or through the webUI) as user 'minidlna' and group 'multimedia'.

Should I see the User 'minidlna' and the group 'multimedia' in the webui 'Users and Groups Setup' section (Setup/Users)? They aren't there. I would like only those in the User group to have access to public folders. I don't want the access open so I did make changes.

Just like a normal user it has to have permissions to read files and browse folders in the folders and sub-folders that it is going to scan.
The default Public folder has such permissions, don't know what permissions and ownership Public/RW/My_Videos (and its files and sub-folders) have.

Here's the Public/RW sub-folder permissions currently. I tried opening the My_Videos and Pictures permissions to see if that would have an effect but it didn't. As I mentions the My_Music folder contains over 17000 tracks so I removed it completely from the scan temporarily. I also had an issue initially with My Videos and My Music having a space but I changed the folder names so the space was changed to the underscore, so My_Music instead of My Music. Permissions:

	Owner	Group	Permissions
Up Folder
Backups	root	users	rwxrwsr--
Favorites	root	users	rwxrwsr--
My_Music	root	users	rwxrwsr--
My_Videos	root	users	rwxrwsrwx
PDF	root	users	rwxrwsr--
Pictures	root	users	rwxrwsrwx
Updates	root	users	rwxrwsr--

Using the webUI, I set the owner to Root with full permissions to read write and browse, the Group to Users with full permission to read, write and browse. I set Other usually to NO ACCESS but I also tried setting to full access for the folders Pictures and My_Videos. I imagine I fubar-ed the permissions but it did work under RC3 so I'm not sure where or when it went south.

The log for forked daapd is similar with permission denied showing as well. I can post that log but figured the problem is related so a solution for one will no doubt lead to a solution with the other.
 

TIA

[João Cardoso]

On Wednesday, July 9, 2014 5:22:40 PM UTC+1, Kevin Roberts wrote:

Greetings!

 

minidlna runs (when called through its initscript 'rcminidlna' or through the webUI) as user 'minidlna' and group 'multimedia'.

Should I see the User 'minidlna'

No. That's only for real users.
 

and the group 'multimedia'

Yes
 

in the webui 'Users and Groups Setup' section (Setup/Users)? They aren't there.

Perhaps a migration issue?
 

I would like only those in the User group to have access to public folders. I don't want the access open so I did make changes.

That was not designed to be that way. Instead, users who could have access to multimedia files should be added to the multimedia group.
And multimedia files and folders should belong to group multimedia. Folders must have (at least) read/browse group permission and files (at least) read permission. Ownership don't need to be multimedia, can/shall be a real user. E.g.:

# ls -la /Public/RO/Music/Sarah\ Vaughan/JazzTime/
drwxr-x---    2 jcard    multimed      1024 May  7 16:06 .
drwxr-x---    3 jcard    multimed      1024 May  7 15:51 ..
-rwxr-----    1 jcard    multimed   4132675 Jan 10  2010 01 Lover Man.mp3
-rwxr-----    1 jcard    multimed   4860448 Jan 10  2010 16 That's All.mp3

I'm the owner, jcard, can do whatever I want; to the group (multimedia) I only gave "ear" and browse permissions.

But you are right, minidlna is faulty in this respect. It accepts a '-u user' command line argument, so it will run as that user (minidlna), *but* it does not runs as the group (multimedia) of that user.

So, I have to fix that. (add a ticket, please)

Meanwhile, try the following (can you read it? a '-' means a line is removed, a '+' a line is added, other lines will be unchanged and used as other lines location context:

--- /etc/init.d/S80minidlna.orig
+++ /etc/init.d/S80minidlna
@@ -14,7 +14,7 @@
 RC_DESC="minidlna daemon"
 
 RC_PIDFILE=/var/run/$NAME/$NAME.pid
-MINIDLNA_ARGS="-u $RC_USER "
+MINIDLNA_ARGS=""
 
 . /etc/init.d/common
 
@@ -51,12 +51,14 @@
        exit 1
 }
 
-check_user $CONF_MINIDLNA /var/lib/$RC_USER
+touch /var/log/minidlna.log
+mkdir -p /var/run/minidlna
+check_user $CONF_MINIDLNA /var/lib/$RC_USER /var/run/minidlna /var/log/minidlna.log
 
 case "$1" in
        start)
                check_shares
-               start $NAME -- $RESCAN $MINIDLNA_ARGS
+               start $NAME --chuid $RC_USER:$RC_GROUP -- $RESCAN $MINIDLNA_ARGS
                ;;
 
        stop) stop $NAME ;;

Did it work?

(...)

The log for forked daapd is similar with permission denied showing as well. I can post that log but figured the problem is related so a solution for one will no doubt lead to a solution with the other.

Try a similar solution

In any case this should be in a different thread, such as "minidlna/forked_daapd permission denied to access multimedia files"

[Kevin Roberts]

 Greetings!

I have a few questions...

 

and the group 'multimedia'

Yes
 

in the webui 'Users and Groups Setup' section (Setup/Users)? They aren't there.

Perhaps a migration issue?

The only groups I see are Users and BT. I think I recall a group multimedia under RC3 but after setting things up, I honestly can't say I ever more than glanced at that Users and Groups Setup section again. You had helped with with some issues with groups and users when I first went to RC2. That said I do see multimedia when looking at the folder permissions (Setup/Folders/Permissions/Users in group) and I see under Owner, forked-daapd user and minidlna daemon.

 

I would like only those in the User group to have access to public folders. I don't want the access open so I did make changes.

That was not designed to be that way. Instead, users who could have access to multimedia files should be added to the multimedia group.
And multimedia files and folders should belong to group multimedia. Folders must have (at least) read/browse group permission and files (at least) read permission. Ownership don't need to be multimedia, can/shall be a real user. E.g.:

# ls -la /Public/RO/Music/Sarah\ Vaughan/JazzTime/
drwxr-x---    2 jcard    multimed      1024 May  7 16:06 .
drwxr-x---    3 jcard    multimed      1024 May  7 15:51 ..
-rwxr-----    1 jcard    multimed   4132675 Jan 10  2010 01 Lover Man.mp3
-rwxr-----    1 jcard    multimed   4860448 Jan 10  2010 16 That's All.mp3

I'm the owner, jcard, can do whatever I want; to the group (multimedia) I only gave "ear" and browse permissions.

 I see your point and, perhaps, this comes under the heading 'best practices'. Now would be the time if I'm to change the setup of the folder structure. Should I move the multimedia folders (pictures, My_Videos, My_Music) out of the Public/RW folder into a multimedia folder and reconfigure the permissions? That said, putting my users into another group only creates something else to be maintained. I only want members of the group users to have access to the NAS box so I'm not sure I see the advantage to also putting those users into another group (multimedia)? It seems like it would be easier for me to put minidlna daemon and forked-daapd user into the users group.

But you are right, minidlna is faulty in this respect. It accepts a '-u user' command line argument, so it will run as that user (minidlna), *but* it does not runs as the group (multimedia) of that user.

So, I have to fix that. (add a ticket, please)

LOL, you understand perfectly what you just said but I'm a little confused? In order to post a ticket, I need to understand what the problem is, You seem to be saying that minidlna is faulty in that the minidlna daemon isn't in the multimedia group? or something like that ;-D

Meanwhile, try the following (can you read it? a '-' means a line is removed, a '+' a line is added, other lines will be unchanged and used as other lines location context:

--- /etc/init.d/S80minidlna.orig
+++ /etc/init.d/S80minidlna
@@ -14,7 +14,7 @@
 RC_DESC="minidlna daemon"
 
 RC_PIDFILE=/var/run/$NAME/$NAME.pid
-MINIDLNA_ARGS="-u $RC_USER "
+MINIDLNA_ARGS=""
 
 . /etc/init.d/common
 
@@ -51,12 +51,14 @@
        exit 1
 }
 
-check_user $CONF_MINIDLNA /var/lib/$RC_USER
+touch /var/log/minidlna.log
+mkdir -p /var/run/minidlna
+check_user $CONF_MINIDLNA /var/lib/$RC_USER /var/run/minidlna /var/log/minidlna.log
 
 case "$1" in
        start)
                check_shares
-               start $NAME -- $RESCAN $MINIDLNA_ARGS
+               start $NAME --chuid $RC_USER:$RC_GROUP -- $RESCAN $MINIDLNA_ARGS
                ;;
 
        stop) stop $NAME ;;

Did it work?

 

I'm pretty sure I'm understanding your shorthand and you want me to edit some files but you forget how little I really know about linux....exactly what am I using to edit the files? I'm pretty sure you don't want me to muck about with a windows editor? When I google file editing in linux, I see something called vi comes up, am I using that?

(...)

The log for forked daapd is similar with permission denied showing as well. I can post that log but figured the problem is related so a solution for one will no doubt lead to a solution with the other.

Try a similar solution

In any case this should be in a different thread, such as "minidlna/forked_daapd permission denied to access multimedia files"

 As the moderator, you can make that change right? I don't know if I am able to change the heading of a thread? I know I can't split off a new thread. Let me know what you're asking or make the changes yourself with my permission.

[João Cardoso]

On Thursday, July 10, 2014 4:35:11 PM UTC+1, Kevin Roberts wrote:

 Greetings!

I have a few questions...

I'm pretty sure that I have extensively replied to this post, but it doesn't show-up... and I just don't want to do it again, sorry :-)

I installed minidlna in my openSUSE-13.1 and guess what -- its runs as the root (Administrator) user!
It looks like "good-practices" are not followed by everyone anymore.
So you, Kevin, humble Alt-F user, feel free to make it run the easiest way for you, not the correct way :-(

Can anybody check how Debian does it?

[Kevin Roberts]

I'm pretty sure that I have extensively replied to this post, but it doesn't show-up... and I just don't want to do it again, sorry :-)

I'm dependent on your consideration or lack of it to help sort out my problems with the new firmware. I understand your frustration with spending the time and effort to construct a reply to only have it go missing but if you won't (re-)answer about the specifics of the problem, I don't see how I can open a ticket as you've suggested. I wouldn't know what to put in it.

It looks like "good-practices" are not followed by everyone anymore.
So you, Kevin, humble Alt-F user, feel free to make it run the easiest way for you, not the correct way :-(

If it wasn't for the problem I've encountered with moving to RC4, I would be blissfully ignorant of such things. Unfortunately, even if I wanted to follow your recommended practices, the missing multimedia group would make that difficult/impossible from the webui?

I found that vi was present and I also installed the vim package and looked at it so I was able to figure out the editing of the file on my own. Can't say I saw a lot of difference between the two editors at least for what I needed to accomplish? Considering your last somewhat unfriendly reply, it seems you're no longer assisting me with this issue so I'm not sure how to proceed?

[João Cardoso]

When I hit the submit button, I got a "something error, reload!". And the post vanished after doing that!

Having web-based apps like Google Groups is like having a disk with intermittent failures and not being able to replace it!

Fortunately, this time I copied the post before doing the "reload" action. And the post does not reflects my bad mood after the issue.

On Saturday, July 12, 2014 2:35:34 PM UTC+1, Kevin Roberts wrote:

I'm pretty sure that I have extensively replied to this post, but it doesn't show-up... and I just don't want to do it again, sorry :-)

I'm dependent on your consideration or lack of it to help sort out my problems with the new firmware. I understand your frustration with spending the time and effort to construct a reply to only have it go missing but if you won't (re-)answer about the specifics of the problem, I don't see how I can open a ticket as you've suggested. I wouldn't know what to put in it.

It looks like "good-practices" are not followed by everyone anymore.
So you, Kevin, humble Alt-F user, feel free to make it run the easiest way for you, not the correct way :-(

If it wasn't for the problem I've encountered with moving to RC4, I would be blissfully ignorant of such things. Unfortunately, even if I wanted to follow your recommended practices,

The easy solution for you is to change permissions on your media folder, so anyone (minidlna) can read and browse through it.
But remember to apply the changes to files and subfolder also! If permissions are wide open your shouldn't have minidlna errors. This worked in RC2 for you, will work for RC4 and will works on all unixes. That is (one of the things) what I call bad pratices, but sometimes we are in a hurry.
Also remember that the log is appended, so the log of a new start of minidlna will be at the end.

Another solution is to start minidlna on behalf of a user that can currently browse and read the files.
This involves editing the /etc/init.d/S80minidlna initscript and will make things more complex in the future. Essencially replace $RC_USER with the username of an user than can currently browse the folder, such as 'joe' (the user must exists)

MINIDLNA_ARGS="-u $RC_USER " # replace this

MINIDLNA_ARGS="-u joe " # with this

the missing multimedia group would make that difficult/impossible from the webui?

Not really.
But first: do you have a multimedia group? What is the content of /etc/groups and /etc/passwd?

cat /etc/passwd # don't be afraid, no password will be shown
cat /etc/group

I found that vi was present and I also installed the vim package and looked at it so I was able to figure out the editing of the file on my own. Can't say I saw a lot of difference between the two editors at least for what I needed to accomplish?

Try 'nano', it's more (in the MS-DOS sense) friendly.
 

Considering your last somewhat unfriendly reply, it seems you're no longer assisting me with this issue so I'm not sure how to proceed?

I apologize if I was unfriendly, that was not my intention.

I was frustrated by the vanished post (which took a lot of time to write) and by the bad-practices of the opensuse minidlna packager (to be fair, it is not openSUSE fault, but PacMan fault, as I downloaded minidlna from an alternative package feeder).

Next I will reboot my laptop and try to see how KUbunto packages minidlna. I have already downloaded all RC3 code to see how exactly I did it before and how compatibility was break. I also have to see if/how Alt-F minidlna changed since RC3 through its several releases.

As you can see I have not giveup on you, it just happens that I'm on holidays and things might took a bit more time to solve.
I understand that you just want a solution, but I hate to give recipes ;-)

[Kevin Roberts]

Greetings!

 

When I hit the submit button, I got a "something error, reload!". And the post vanished after doing that!

Having web-based apps like Google Groups is like having a disk with intermittent failures and not being able to replace it!

 As you know, I posted that one message in this very thread at least 6 times before it finally took using an email response so I fully understand about that! :-)

 

The easy solution for you is to change permissions on your media folder, so anyone (minidlna) can read and browse through it.
But remember to apply the changes to files and subfolder also! If permissions are wide open your shouldn't have minidlna errors. This worked in RC2 for you, will work for RC4 and will works on all unixes. That is (one of the things) what I call bad pratices, but sometimes we are in a hurry.
Also remember that the log is appended, so the log of a new start of minidlna will be at the end.

I thought that I had the permission open for the Pictures and My_Videos folders? I set Other to Read/Write/Browse in the webui, isn't it open already?

My_Videos

root

users

rwxrwsrwx

Pictures

root

users

rwxrwsrwx

These permissions were applied to subfolders and files as well. I'll try any suggestion you have including relocating the folders, changing user, group or other permissions etc. in order to determine where the problem is but I probably wouldn't want to leave things completely open whether I conform to best practices or not in other regards.

 

Another solution is to start minidlna on behalf of a user that can currently browse and read the files.
This involves editing the /etc/init.d/S80minidlna initscript and will make things more complex in the future. Essencially replace $RC_USER with the username of an user than can currently browse the folder, such as 'joe' (the user must exists)

MINIDLNA_ARGS="-u $RC_USER " # replace this

MINIDLNA_ARGS="-u joe " # with this

 

This I think would be the solution of last resort but we could certainly try for testing?

 

But first: do you have a multimedia group? What is the content of /etc/groups and /etc/passwd?

cat /etc/passwd # don't be afraid, no password will be shown
cat /etc/group

I'm sure the group multimedia is there as well as the minidlna daemon and the forked_daapd user as I can see them listed when I look at the folder permission settings for Owner and Group but here's the listings:

login as: root

root-192.168.1.109's password:

COLUMNS=80;LINES=24;export COLUMNS LINES;

[root@DNS-323]# cat /etc/passwd

root:x:0:0:root:/root:/bin/sh

daemon:x:1:1:daemon:/usr/sbin:/bin/sh

bin:x:2:2:bin:/bin:/bin/sh

sys:x:3:3:sys:/dev:/bin/sh

sync:x:4:100:sync:/bin:/bin/sync

at:x:5:8:at Daemon:/home/at:/bin/sh

#dbus 6

ftp:x:7:7:FTP User:/var/run/vsftpd:/bin/sh

mail:x:8:8:mail:/var/spool/mail:/bin/sh

#cups 9

#ushare 10

#minidlna 11

#fuppes 12

#transmission 13

#mediatomb 14

#mt-daapd 15

#forked-daapd 16

#automatic 17

www-data:x:33:33:www-data:/var/www:/bin/sh

backup:x:34:34:backup:/var/backups:/bin/sh

sshd:x:67:67:SSHD User:/var:/bin/sh

#avahi 68

#ups 69

nobody:x:99:98:nobody:/home:/bin/sh

Sabertooth:x:1000:100:Sabertooth:/home/Sabertooth:/bin/sh

Vibo:x:1001:100:Vivian:/home/Vivian:/bin/sh

MajorEvent:x:1002:100:MajorEvent:/home/MajorEvent:/bin/sh

BD-670:x:1003:100:BD-670:/home/BD-670:/bin/sh

Boss:x:1004:100:Boss:/home/Boss:/bin/sh

Sandman:x:1005:100:Sandman:/home/Sandman:/bin/sh

dbus:x:6:3:DBUS Daemon:/var/lib/dbus:/bin/false

avahi:x:68:68:avahi daemon:/var/run/avahi-daemon:/bin/false

daapd:x:16:80:forked-daapd user:/var/lib/daapd:/bin/false

mpd:x:23:80:MPD user:/var/lib/mpd:/bin/false

minidlna:x:11:80:minidlna daemon:/var/lib/minidlna:/bin/false

transmission:x:13:201:Transmission daemon:/var/lib/transmission:/bin/false

lighttpd:x:35:81:Lighttpd daemon:/var/lib/lighttpd:/bin/false

[root@DNS-323]# cat /etc/group

root:x:0:

daemon:x:1:

bin:x:2:

sys:x:3:dbus

adm:x:4:

tty:x:5:

disk:x:6:

ftp:x:7:

at:x:8:

backup:x:34:Sabertooth,Boss

utmp:x:43:

sshd:x:67

#avahi 68

#multimedia 80

#network        81

netdev:x:82:

#nut 84

nobody:x:98:

nogroup:x:99:

users:x:100:Sabertooth,Vibo,BD-670,Boss,Sandman,MajorEvent

avahi:x:68:avahi

multimedia:x:80:daapd,minidlna,mediatomb,mpd,ushare

BT:x:201:transmission,Sabertooth,Boss

network:x:81:lighttpd

[root@DNS-323]#

Try 'nano', it's more (in the MS-DOS sense) friendly.
 

 Installed. Looks interesting, I'll give it a try.

I was frustrated by the vanished post (which took a lot of time to write) and by the bad-practices of the opensuse minidlna packager (to be fair, it is not openSUSE fault, but PacMan fault, as I downloaded minidlna from an alternative package feeder).

I knew that was the case so don't worry too much. I hope you also understand how a reply like that might be misunderstood by the party it's directed at. I felt you were angry with my recalcitrant response to your best practices.

As you can see I have not giveup on you, it just happens that I'm on holidays and things might took a bit more time to solve.
I understand that you just want a solution, but I hate to give recipes ;-)

 

I certainly have no expectation of an immediate solution or wish to pressure you in that regard. Please enjoy your vacation! This is NOT a critical issue for me so I'm more than willing to accept your timeline as you see fit.

Taking a step backward...

As I previously indicated I had edited the init script as you suggested. The result was that the permission denied error was not seen in the log however the folders were not scanned so the database has zero (0) entries.

The edited script for your review in case I screwed up:

login as: root

root-192.168.1.109's password:

COLUMNS=80;LINES=24;export COLUMNS LINES;

[root@DNS-323]# vim /etc/init.d/S80minidlna

#!/bin/sh -e

NAME=minidlna

DESC="MiniDLNA is a DLNA/UPnP-AV server."

TYPE=user

NEED_ALTF_DIR=1

CONF_MINIDLNA=/etc/$NAME.conf

RC_USER=$NAME

RC_USERN=11

RC_GROUP=multimedia

RC_GROUPN=80

RC_DESC="minidlna daemon"

RC_PIDFILE=/var/run/$NAME/$NAME.pid

MINIDLNA_ARGS=""

. /etc/init.d/common

check_shares() {

        if test -r "$CONF_MINIDLNA"; then

                if grep -q '^#force_rescan=yes' $CONF_MINIDLNA; then

                        RESCAN="-R"

                fi

                MDLNA_DIR="$(awk -F= '/^media_dir/{printf "%s;", $2}' $CONF_MINI

DLNA)"

                OIFS="$IFS"; IFS=";"

                for i in $MDLNA_DIR; do

                        if echo $i | grep -q ^/ ; then

                                mdir=$i

                        else

                                mdir=${i:2}

                        fi

                        if ! test -d "$mdir"; then

                                echo "$NAME: Share $mdir does not exists."

                                exit 1

                                #sed -i 's|^media_dir='$i'|# directory not found

: &|' $CONF_MINIDLNA

                        else

                                conf_ok="yes"

                        fi

                done

                IFS="$OIFS"

                if test -z "$conf_ok"; then

                        echo "$NAME: can't be started, no shares are configured.

"

                        exit 1

                fi

                return 0

        fi

        echo "$NAME: Configuration file does not exists."

        exit 1

}

touch /var/log/minidlna.log

mkdir -p /var/run/minidlna

check_user $CONF_MINIDLNA /var/lib/$RC_USER /var/run/minidlna /var/log/minidlna.

log

case "$1" in

        start)

                check_shares

                start $NAME --chuid $RC_USER:$RC_GROUP -- $RESCAN $MINIDLNA_ARGS

                ;;

        stop) stop $NAME ;;

        status) status $NAME ;;

        reload) reload $NAME 1 ;;

        restart) restart $NAME ;;

        *)

                echo "Usage: $0 {start|stop|status|reload|restart}"

                exit 1

                ;;

esac

[root@DNS-323]#

(I made this copy at the time of editing so that's why vim was used.) Let me know if I messed up the edit or should return to the original script.

I also note some unusual behavior where sometimes the service won't re-start after being stopped until a reboot but this behavior is unrelated to the script changes and occurred before and after those changes.

[João Cardoso]

On Sunday, July 13, 2014 6:11:12 PM UTC+1, Kevin Roberts wrote:

Greetings!

This is very out of topic now.

Better start new threads, with a clear Subject, and start *summarizing* the issues.

-Just to let you know that I have installed your /etc/passwd and /etc/group in my system and that the multimedia group appears, as you can see in the screen shot. Under RC3, that group would not appear, but it should appear under RC4.
In the new thread, please say if you have a file named /Alt-F/usr/www/cgi-bin/usersgroups.cgi

-There is *no* reason for minidlna not being able to scan your folders if they are wide-open. You say that you have edited the initscript and no error appears now, but also you don't include the log. You can increase the log verbosity, if needed, by editing /etc/minidlna.conf and proceeding accordingly (log_level=debug).
As things are so messed up by now, the best is probably to start minidlna from a fresh start, removing all its own files -- un-installing it is *not* enough! This has the inconvenient of requiring a full rescan of your media, so you should start with a small set of folders/subfolder/files to see if everything is OK.
The procedure is, sequence is important:
-stop minidlna
-uninstall minidlna
-remove
  /var/lib/minidlna folder and files
  /etc/minidlna.conf
  /etc/minidlna folder if it exists
  /var/run/ /var/log files and folders with minidlna in its name
-reboot, just for sure -- verify that no file or folder with minidlna in its name exists in the above locations
-verify that you have a set of folders, subfolders and multimedia files (a few dozens) with permissions for everyone to read and browse in a given location.
-install minidlna
-configure it
-start it
-append the minidlna log.

Joao

[Kevin Roberts]

Better start new threads, with a clear Subject, and start *summarizing* the issues.

Did you want me to do this with my next reply? What subject do you suggest then?

[João Cardoso]

On Friday, July 18, 2014 3:54:56 PM UTC+1, Kevin Roberts wrote:

Better start new threads, with a clear Subject, and start *summarizing* the issues.

Did you want me to do this with my next reply?

Yes, please.