search

sciapp / sampledb

Sample and Measurement Metadata Database
https://scientific-it-systems.iffgit.fz-juelich.de/SampleDB/
MIT License
21 stars 11 forks source link

Failed to write to the directory given as FILE_STORAGE_PATH. #5

Closed NicolasCARPi closed 4 years ago

NicolasCARPi commented 4 years ago

Hello,

Just trying out the software with the commands provided in the README. The sampledb container fails to start with the error in title. Directory specified is of course writable. Even tried with /tmp/files.

So I looked into the code and commented these lines. Now it works. I mean at least it launches, trying to upload a file results in error 500 (permission denied), so that fixes nothing...

Any idea?

FlorianRhiem commented 4 years ago

Hello Nicolas,

these lines are there to ensure that the Docker container can write to that directory. The commands in the README assume that there is no files subdirectory yet in the directory you are in, so that it will be created and so that it will be writable inside the container.

When you say you tried with /tmp/files, do you mean you mounted /tmp/files into the container or do you mean you changed the SAMPLEDB_FILE_STORAGE_PATH to /tmp/files?

What host system are you using? Has the files subdirectory been created? If so, what are the permissions and who is the owner for this directory?

NicolasCARPi commented 4 years ago

The commands in the README assume that there is no files subdirectory yet in the directory you are in, so that it will be created and so that it will be writable inside the container.

Agreed.

When you say you tried with /tmp/files, do you mean you mounted /tmp/files into the container or do you mean you changed the SAMPLEDB_FILE_STORAGE_PATH to /tmp/files?

Yep, mounted my local /tmp/files into the container.

What host system are you using?

Archlinux.

Has the files subdirectory been created?

Yes.

If so, what are the permissions and who is the owner for this directory?

drwxr-xr-x 2 root root

I'm able to fix the issue by commenting out the USER instruction in the Dockerfile. I think the issue is with the sampledb that runs in the container. Because the container is always restarting with the user sampledb, I can't go in it and check what is the userid. But I'm pretty sure that if I chown the files folder to that userid/group, it will work. For instance, the pgdata folder is owned by userid 999 and group root.

FlorianRhiem commented 4 years ago

I prefer to only let containers run as root when necessary, so the Dockerfile creates the sampledb user and uses it. I would also prefer if the user doesn't have to create the files directory and chown it themselves, so my current approach to fixing this is that the container is started as root, chowns the directory and then switches to the sampledb user for starting the SampleDB server, as done in this commit.

Could you verify that this would solve the issue on your system as well? Do you perhaps know a better approach to fix this?

NicolasCARPi commented 4 years ago

I prefer to only let containers run as root when necessary

Agreed.

Could you verify that this would solve the issue on your system as well?

I can confirm that it works!

Do you perhaps know a better approach to fix this?

Honestly, the issue lies within docker, where volumes get an id that might not correspond to a real user on the host. I don't think there is a "proper" fix. I think you approach is valid.

FYI, I faced a bit of the same issue in my project, and this is how we fixed it: https://github.com/elabftw/elabimg/pull/10/files This approach allows the end user to specify the UID and GID of the user in the container. Useful if you're running it on a system that enforces UID/GID (NFSv4).

FlorianRhiem commented 4 years ago

This should be fixed by 5d1ce3ac1bb1764f2e5ac1b7463b203a86b8dd70. These changes will be part of the next release.

Thanks again for reporting this!