filebrowser: timeout on commands that connect to a locked database
Description Any command I pass through docker-compose (e.g. docker-compose exec filebrowser ./filebrowser config cat) returns timeout
Expected behaviour Use the command line utility to manipulate users and config
What is happening instead?
Command returns
2019/01/09 10:41:54 timeout
Container logs (docker-compose logs filebrowser) returns
filebrowser | 2019/01/09 10:36:26 Using config file: /.filebrowser.json
filebrowser | 2019/01/09 10:36:26 Listening on [::]:80
How to reproduce? Here’s my minimal docker-compose.yml for reproducing purposes
filebrowser:
container_name: filebrowser
image: filebrowser/filebrowser:v2.0.0-rc.1
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 19 (12 by maintainers)
Can we reopen this since the repository is active again?
I have the same identical issue when I am trying to run filebrowser inside a pod. Via command line I am not able to do anything. Every command gives me a timeout including export ones. Anyway I do not understand how can the filebrowser configuration works after then I stopped it. Via command line seams that only “version” is working fine. Any idea?
This is an example:
/opt $ /filebrowser users --help Users management utility.
Usage: filebrowser users [command]
Available Commands: add Create a new user export Export all users to a file. find Find a user by username or id import Import users from a file ls List all users. rm Delete a user by username or id update Updates an existing user
Flags: -h, --help help for users
Global Flags: -c, --config string config file path -d, --database string database path (default “./filebrowser.db”)
Use “filebrowser users [command] --help” for more information about a command. /opt $ /filebrowser users ls 2022/12/28 15:41:30 timeout /opt $ /filebrowser version File Browser v2.23.0/02db83c7 /opt $
posting this if it helps anyone (or someone comes up with a better solution), I wrote a
Dockerimage(not as tiny as the official one) that kind of works around this:Dockerfile:
config.json
startup.sh
now if you want to execute some commands you can do the following:
@hacdias, after the proof of concept by @alpetric, would it be possible to add support for communication between filebrowser instances?
Since all the calls to filebrowser are expected to be done with the same exact binary, we can add checks to somehow ensure that these admin calls are only produced by it.
Optionally, the lock can be a pipe, so calls between filebrowser instances are done through it, instead of using the (local) network.
Did a small experiment to isolate the issue:
I wrote a simple Dockerfile:
Using that file I:
Now I have a shell inside this vanilla image with filebrowser
My suspicion is that this is not a Docker issue but in general, while a filebrowser instance is running, some commands will timeout when trying to modify/read the currently used db/config.
My tests basically show that you if you want to add users for example, you need to stop the filebrowser process, run the
filebrowser users addcommand, then restart filebrowser. In my opinion, it would be great to have the ability to add users without restarting.I’d say that docker is running
filebrowser ./filebrowser config cat. The command should bedocker-compose exec filebrowser config cat.Since there is no other binary/executable in the container, it is ok for the entrypoint to be
filebrowser. Overall, the container replaces the binary functionally, it is not a VM with some content.