Skipping library directory /path/to/music, could not dereference: Permission denied

[attilagyorffy]

Hi,

I am running forked-daapd with issues on Ubuntu Natty, I am getting the following error:

cat /var/log/forked-daapd.log [2011-08-27 23:05:46] main: Forked Media Server Version 0.18 taking off [2011-08-27 23:05:46] main: mDNS init [2011-08-27 23:05:46] mdns: Avahi state change: Client running [2011-08-27 23:05:46] db: Could not prepare statement: no such table: admin [2011-08-27 23:05:46] db: Could not check database version, trying DB init [2011-08-27 23:05:49] scan: Skipping library directory /media/Elements/Media/Music/lossless, could not dereference: Permission denied

I've installed the package through http://ftp.uk.debian.org/debian/ sid main, the library successfully shows up but it is empty. I've removed previously installed packages and all files that forked-daapd was previously storing on my system, including /var/cache/forked-daapd or the logs.

Needless to say that my library path has daapd as its owner set up, even the music group that is the owner has the daapd user associated to it.

Tried so many times but I cannot get it running. Could this be a libdispatch issue?

Any help is greatly appreciated.

[Legogris]

EDIT: I had the same issue. My problem was that the I didn't have write rights to the directory in my library path. Seems strange that this would be needed, but giving the daapd user w fixed it for me.

[attilagyorffy]

Still cannot get this working, tried adding all permissions: cat /etc/group | grep -i music => music:x:1002:attila,daapd chown -R daapd:music /media/Elements/Media/Music/lossless chmod -R 777 /media/Elements/Media/Music/lossless /etc/init.d/forked-daapd status => forked-daapd is not running. /etc/init.d/forked-daapd force-reload /etc/init.d/forked-daapd start => Starting RSP and DAAP media server: main: Forked Media Server Version 0.18 taking off => forked-daapd.

And it is still the same... Going a bit nuts.

[attilagyorffy]

Even chmod -R 777 does not resolve the issue. Funny thing is that I am capable of browsing the directory fine through other services, such as netatalk, samba, etc.

[attilagyorffy]

No idea how I managed to close the issue but the problem still exists on version 0.19.

[attilagyorffy]

@Legogris: What exactly have you done to get it working? I've tried so many things and I still can't get it working.

[Legogris]

My issue was fixed by giving the user running forked-daapd full rights to the library folder and all subfolders and directories.

[attilagyorffy]

The question really is: Why do you need to add write rights to the daapd user?

[Legogris]

EDIT: Too fast, sorry :)

[attilagyorffy]

@Legogris: Please read my previous comment first. I've tried changing the directory rights already. chmod -R 777. I've gone through that. Generally speaking I wouldn't be concerned about 777 either (given that it is a home media server and is not accessible from outside of the network) but I don't understand why forked-daapd would need write rights to the media folder. Everything is stored outside of the media folder, logs, the sqlite3 database file, everything.

[Legogris]

Sorry, I thought it was a "how" and not a "why" I saw. And I agree, it is peculiar.

[strawp]

I'm getting this error attempting to scan an external drive. Scanning on the same HDD that Ubuntu is installed on is fine. Could this be an issue just with external drives? Does anyone have a collection on an external drive working OK?

[strawp]

Resolved: I think realpath() has difficulty if a point in the path is not readable by the user running it. So in my case my external drive was mapped to a dir in /media which did not have read set on "other", so I did chmod o+r on it. Also some files in the music dir were not in the "root" group, which caused problems. Seems to have found the files now :)

[fenollp]

Indeed. realpath(3) receives EACCES if only one directory in the path/to/your/music (eg. "your/") is not o+r or o+x. This means you can't store your music inside your /home (as you wouldn't chmod o+rx /home/$USER). Note, user or group ownership is irrelevant here.
Is realpath() really needed? You don't need a file's absolute path to acces it. Why use this prone-to-error function, as most users would be storing their music collection under their /home? Thanks

[serverwentdown]

A solution to running this in /home/$USER is to give group permissions to all relevant folders, and then add daapd to your user group.