Dealing with RO file systems and indexing

[nelgin]

I'm pretty freakish about security on my system, so let me explain my subsonic layout. This is a Linux system, btw.

All my mp3 file are in /mp3 which is a read-only file system. Before I make changes to tags or whatever, I remount as re-write, make my changes, then remount it read-only. This aids in quickly restarting the system from any sort of crash due to not having to fsck the file system.

All the mp3 files are owned by me with rw permissions, and group mp3 with r permissions only. There are no permissions for other. That means only myself or members of the "mp3" group have access to the music files.

Subsonic is installed in /home/subsonic and is in the mp3 group.

This means my music and OS is pretty safe should there be any sort of issue with subsonic because at no point is it running as root, and at no point does it have write permissions to any of my files.

Now, the problem comes when it's time to index the files and attempts to create an album art. As you can imagine, this generates a lot of write errors.

The only solutions I can think of are to have a standalone index module that can be run by a root cronjob that will:
Change the file system to read/write temporarily
Index the files as root user to allow for writing the files with album art
Change the file system back to wo

Anyone have a better suggestion?

[bushman4]

I do not believe that Subsonic creates Album Art thumbnails and the like during Search Indexing... I believe it creates them "on the fly" when a particular folder is accessed directly or referenced (via the home page "Random" or "Newest" or whatever).

At that time the art is rendered from the tags or from image files and converted to a thumbnail version.

What do the write errors look like?

I don't think there is a solution to your problem at this time...

Glenn

[BKKKPewsey]

Unless you edit your tags via SS I do not think SS writes anything to your music files/directories.
All the album art thumbnails are stored in the subsonic/thumbs directory
so providing SS has write access to its own directories (don't forget playlist directory) there shouldn't be a problem.

[nelgin]

It could be a different issue actually, because I'm just seeing this in one particular directory.

1120811122 [btpool0-3135] WARN org.mortbay.log - /coverArt.view: java.io.IOException: Failed to create thumbnail for /mp3/pathto.mp3. null

I'm only seeing this the one directory. I'll check again tomorrow after another run. This is from an old backup log cos I wiped my current ones when I restarted subsonic.

[nelgin]

Unless you edit your tags via SS I do not think SS writes anything to your music files/directories.
All the album art thumbnails are stored in the subsonic/thumbs directory
so providing SS has write access to its own directories (don't forget playlist directory) there shouldn't be a problem.

Hmm, didn't consider that. I thought it was trying to update the album art embedded in the mp3 file itself.

As for the playlists, I have all that stored in the /home/subsonic directory. I had to edit subsonic.sh to make sure everything (including tmp) are included within that specific directly to keep it self-contained.

I'll have to look into why I'm getting this specific error then.