search

rawdlite / docker-rompr

setup Rompr using docker
Apache License 2.0
13 stars 7 forks source link

how to get perms for bind mounts for prefs and such #10

Open g13092 opened 3 months ago

g13092 commented 3 months ago

I'm running via compose with the following settings: `version: "3.3"

services: rompr: image: chrll/rompr container_name: rompr restart: unless-stopped ports:

But, the log in the docker complains

rm: cannot remove '/var/run/nginx.pid': No such file or directory Restarting PHP 7.4 FastCGI Process Manager: php-fpm7.4.

And when i go to the webpage for the interface, I get: ` _Warning: fopen(prefs/prefs.lock): failed to open stream: Permission denied in /app/rompr/includes/prefs.class.php on line 356

Warning: fclose() expects parameter 1 to be resource, bool given in /app/rompr/includes/prefs.class.php on line 357

Warning: fopen(prefs/prefs.var): failed to open stream: Permission denied in /app/rompr/includes/prefs.class.php on line 416 Fatal Error - Could not open the preferences file

Warning: error_log() expects parameter 2 to be int, string given in /app/rompr/includes/prefs.class.php on line 437

Warning: unlink(prefs/prefs.lock): No such file or directory in /app/rompr/includes/prefs.class.php on line 361`

from reading at fatgerman's git, I get the impression I need to set a PID and GID in this compose file or do something on the server where those bind mounts live to get write access._ '

Any thoughts on this?

rawdlite commented 3 months ago

1.) You load the image 'chrll/rompr'. This is not an image I build or maintain. 2.) The error you report looks like a permission problem.

HTH

g13092 commented 3 months ago

OOPS! I have both yours and this one in the same file, and I commented out one to try the other. I intended to delete the other when I pasted in here so it wouldn't be confusing, but I made it worse!

The result is similar running your image:
image permission issue vibes.

I believe the container is running as root. I tried from my user account and as root, both times uid was 0. The locations I am trying to bind are as such:

root@openmediavault:/srv/0c678f4d-ccb8-4aea-a90a-f8153588a6b9/appdata/rompr# ls -lrt
total 16
drwxrwxr-x+  5 root users 4096 Nov 25  2022 albumart
drwxrwxr-x+ 15 root users 4096 Oct 17  2023 prefs

If I comment these out and just run without them, the container runs fine, I just lose any database or preferences at each restart. I feel like an idiot when it comes to linux perms...

rawdlite commented 3 months ago

I have both yours and this one in the same file, and I commented out one to try the other.

I see where that is confusing. I haven't touched this repository in a long time since i moved to Lyrion (https://sites.google.com/view/theaudioniche/lms) as it supports Qobuz. In the meantime @asktoby was so kind to build images with the latest version of rompr and put them on dockerhub. The code in Dockerfile seems to be the same.

If I comment these out and just run without them, the container runs fine

That makes it very likely a permission problem

I just lose any database or preferences at each restart.

Actually that should not happen with a simple restart.

/srv/0c678f4d-ccb8-4aea-a90a-f8153588a6b9/

Is this an external disk mounted? What filesystem is the harddrive? I had permission issues with FAT in the past.

If this is a local installation and security is not an issue, you could try chmod -R o+rw /srv/0c678f4d-ccb8-4aea-a90a-f8153588a6b9/appdata/rompr and see whats happen.

I might write a new Dockerfile for bookworm and test on a Pi5 if it will still be raining on the WE. HTH

g13092 commented 3 months ago

I thought it seemed permission-like. It is local, so I might give the chmod a try. The filesystem is ext4 on the disks, that mount is a mergerfs pool of several physical disks. I put all my dockers in appdata with mostly similar permissions, though some do call out UID and GID. I was trying the chrll image because it has the 2.x version of rompr.

So, why should the database and prefs remain intact? They persist within the volume? Maybe the key is how I'm restarting, maybe it's wiping out the volume...

rawdlite commented 3 months ago

I played around some and i think i identified your issue. When you restart the docker container the volume persist. Except when you modify the docker-compose.yml. Then the container gets recreated and now the volume setup inside the container does not fit. This gives the app/rompr/includes/prefs.class.php Permission denied error as php tries to access a file where there is none. What you need to do when you change the volume definition in the docker-compose.yml is to remove the old container and create a new one.

docker-compose stop rompr docker-compose rm rompr docker-compose up -d

OTOH since albumart, prefs etc survive a container restart provided the volume configuration in the docker-compose.yml is not altered, i see very little value in exposing /prefs and /albumart to the host. If you really need to access these directories you can do so with

docker exec -it rompr bash

I just uploaded a new version that uses rompr 2.15 and debian bookworm. Until the the mixup on dockerhub is sorted i suggest you build a local image. There is a build-local script in the repository. HTH

g13092 commented 3 months ago

Interesting. I do normally delete the container if I'm planning on pulling an update & I don't normally set up to pull each time I start. I thought I knew where the volume lives, but I must not understand docker volumes correctly...

There's a problem with dockerhub? I will probably look at local build this weekend, I've never dug into that aspect.

While tooling around inside the running container, I did notice (and like fatgerman says in his instructions) that www-data is the owner inside. I'm wondering if I can just define the PID and GID in my compose file? but, I'm not sure what it should be to have proper write access... I would have thought root would cover those sins (while making new sins).

Thanks for looking into it!

g13092 commented 3 months ago

oh, forgot to say, tried the chmod.
image

I did some stop start up down testing this evening. If I just stop and don't remove the container, when I start again, it remembers the music collection and album art. If I down and then remove the container, when I bring it back up, we're back to empty music collection and having to enter the address of the mpd server again. So, it seems contrary to your findings. Again, could be my old brain being a little too smooth for docker :D

rawdlite commented 3 months ago

If I just stop and don't remove the container, when I start again, it remembers the music collection and album art. If I down and then remove the container, when I bring it back up, we're back to empty music collection and having to enter the address of the mpd server again. So, it seems contrary to your findings.

Actually this is exactly what i have been trying to say. When you don't remove your container the volumes persist. Therefore i question the necessity of exposing directories to the host.

When you still want to add volume configurations though, you need to make sure you have removed any old container (and its volumes) after you made changes to the volume configuration before bringing the container up again. (docker-compose rm rompr) Use 

docker-compose ps -a

to check for existing containers. Remove all rompr container.

Also it is important to let the docker container create the directories. In your case this means /srv/0c678f4d-ccb8-4aea-a90a-f8153588a6b9/appdata/rompr should be an empty directory and bringing up the container (docker-compose up) will then create the sub-directories prefs and albumart in there. When empty sub-directories exist before you bring up the container then prefs and albumart inside the container will be overwritten with empty dirs. When the sub-dirs prefs and albumart are empty, remove them before bringing up the container.

oh, forgot to say, tried the chmod.

Yeah, sorry that was the wrong trail. The errors you see have nothing to do with permission. The error messages are misleading. In your attempt to get a rompr container running you created leftover containers and empty directories. Start from a blank slate (no container, no sub-dirs) and you should be fine.

Please report on the local build. I changed the documentation and it should now reflect on how to use the local build images. HTH

g13092 commented 3 months ago

local build worked perfectly. trying to mount the prefs and albumart dirs failed again. However, I figured out that the system, OMV, has some funny configs under the hood. I need to read more about what's going on there. Bind mounts work fine for other containers on this system... to be continued.