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)

Most upvoted comments

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:

FROM alpine

# Install dependencies
RUN apk add curl npm bash
RUN npm install -g pm2

# Install filebrowser
RUN curl -fsSL https://filebrowser.xyz/get.sh | bash

# Copy files/scripts
COPY config.json /.filebrowser.json
COPY startup.sh /startup.sh

EXPOSE 80

CMD ["./startup.sh"]

config.json

{
  "port": 80,
  "baseURL": "",
  "address": "0.0.0.0",
  "log": "stdout",
  "database": "/database.db",
  "root": "/srv"
}

startup.sh

#!/bin/bash
pm2 start filebrowser
pm2 logs

now if you want to execute some commands you can do the following:

### Example Docker
# Adding user on a running container called "filebrowser"
docker exec filebrowser bash -c 'pm2 stop filebrowser && filebrowser users add john secret --perm.execute=false; pm2 start filebrowser'

# Removing user
docker exec filebrowser bash -c 'pm2 stop filebrowser && filebrowser users rm john; pm2 start filebrowser'

@hacdias, after the proof of concept by @alpetric, would it be possible to add support for communication between filebrowser instances?

  • Filebrowser is executed once and, as usual, it gets access to the database. Additionally, it generates a lock (say an envvar or a file).
  • When a subcommand (users, cmds, rules, etc.) is executed, the lock is checked.
    • If the lock does not exist, proceed as usual.
    • If the lock exists, do not open the database. Make a call to the main instance instead.

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:

FROM ubuntu:18.04

MAINTAINER Inpher <info@inpher.io>

# Install dependencies
RUN apt-get update && apt-get install -y build-essential curl

# Install filebrowser
RUN curl -fsSL https://filebrowser.xyz/get.sh | bash

EXPOSE 8080

Using that file I:

# build image
docker build --tag=fb-test

# run image (bash)
docker run -it --rm --name=filebrowser fb-test -p 8080:8080 bash

Now I have a shell inside this vanilla image with filebrowser

root@d39df38f4a93:/# filebrowser version
File Browser version v2.0.0

# To be expected as I never ran filebrowser before
root@d39df38f4a93:/# filebrowser config cat
2019/01/23 18:06:44 ./filebrowser.db does not exist. Please run 'filebrowser config init' first.

# running filebrowser
root@d39df38f4a93:/# filebrowser -a 0.0.0.0
2019/01/23 18:07:27 No config file used
2019/01/23 18:07:27 Listening on [::]:8080

# interrupting it with <ctrl-c> and running the users ls command (works)
root@d39df38f4a93:/# filebrowser users ls
ID  Username  Scope  Locale  V. Mode  Admin  Execute  Create  Rename  Modify  Delete  Share  Download  Pwd Lock
1   admin     .      en      mosaic   true   true     true    true    true    true    true   true      false

# now comes the interesting part

# running filebrowser in background
root@d39df38f4a93:/# filebrowser -a 0.0.0.0 &
[1] 32
root@d39df38f4a93:/# 2019/01/23 18:09:20 No config file used
2019/01/23 18:09:20 Listening on [::]:8080

root@d39df38f4a93:/# filebrowser users ls
2019/01/23 18:11:08 timeout

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 add command, 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 be docker-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.