Install File Browser to Webserver Running on VPS

Install File Browser for Webserver Running on VPS

1. Base web stack (nginx + php‑fpm + shared `www`)

docker-compose.yml in /root/webserver:

services:
  nginx-webserver:
    image: nginx:alpine
    container_name: nginx-webserver
    restart: unless-stopped
    volumes:
      - ./www:/usr/share/nginx/html         # shared webroot
      - ./conf.d:/etc/nginx/conf.d          # vhost configs
    networks:
      - web
    depends_on:
      - php-fpm
        
  php-fpm:
    image: php:fpm-alpine
    container_name: php-fpm
    restart: unless-stopped
    volumes:
      - ./www:/usr/share/nginx/html         # same path as nginx
    networks:
      - web

networks:
  web:
    external: true

This pattern (nginx + php‑fpm containers sharing the same bind‑mounted webroot) is the standard way to serve PHP apps with Docker.

2. Add File Browser with shared `www`

File Browser runs in its own container but sees the same ./www tree, and persists its own DB/config under ./filebrowser:

  filebrowser:
    image: filebrowser/filebrowser:latest
    container_name: filebrowser
    restart: unless-stopped
    volumes:
      - ./www:/srv                          # same webroot, presented as /srv
      - ./filebrowser/database:/database    # File Browser DB dir
      - ./filebrowser/config:/config        # File Browser config dir
    networks:
      - web
    expose:
      - "80"

Key points:

Mount /srv as the “root” File Browser will show; all site folders (mysite.com, example.com, etc.) appear under it.
Mount /database and /config as directories, not individual files, so the container can create filebrowser.db and settings.json inside them.

Host prep (done once):

cd /root/webserver
mkdir -p filebrowser/database filebrowser/config

Then:

docker compose up -d filebrowser

3. Correct permissions for File Browser

Because these are bind‑mounts, Docker does not manage permissions; the host must allow the container user to read/write the mounted dirs.

You used a pragmatic approach:

Make File Browser’s own dirs writable:

cd /root/webserver
chmod -R 777 filebrowser

Once confirmed working, you can tighten later (see section 5).
File Browser then starts correctly and creates /config/settings.json and /database/filebrowser.db inside the container.[

4. Permissions for `www` so nginx + php‑fpm work

For PHP sites, a good baseline is:

Owner has read/write.
Web server user/group has read/execute.
Files are 644, directories 755.

You initially did:

cd /root/webserver

# Make your chosen user the owner; www-data as group
chown -R your_user:www-data www/

# Directories 755, files 644
find www/ -type d -exec chmod 755 {} \;
find www/ -type f -exec chmod 644 {} \;

This gives nginx/php‑fpm read access via group/other, which is the typical layout for /var/www/html on Linux systems.[

If you ever break it by tightening too far and get 404/403 again, you can safely restore:

cd /root/webserver
find www/ -type d -exec chmod 755 {} \;
find www/ -type f -exec chmod 644 {} \;

(re‑chown as needed).

5. Optional: tighten File Browser perms later

Once everything is stable:

Decide which user should “own” both www and File Browser’s metadata (e.g., a non‑root user webuser):


adduser webuser       # if not already created
id webuser            # note uid/gid, e.g. 1001:1001

Set ownership/perms:

cd /root/webserver
chown -R 1001:1001 www filebrowser # replace with your uid:gid
find www/ -type d -exec chmod 755 {} \;
find www/ -type f -exec chmod 644 {} \;
chmod -R 750 filebrowser  # tighter on FB’s own dirs

Make File Browser run as that uid:gid:

  filebrowser:
    image: filebrowser/filebrowser:latest
    container_name: filebrowser
    user: "1001:1001"        # from id webuser
    restart: unless-stopped
    volumes:
      - ./www:/srv
      - ./filebrowser/database:/database
      - ./filebrowser/config:/config
    networks:
      - web
    expose:
      - "80"

Running the container with user: "UID:GID" keeps ownership and permissions consistent between host and container.[

If you prefer to keep everything root‑owned on a single‑tenant VPS, you can instead:

chown -R 0:0 www filebrowser
chmod -R 755 www
chmod -R 750 filebrowser

and add:

    user: "0:0"

to filebrowser. This is simpler and still avoids 777 on www while allowing File Browser to write to its own dirs.[

6. Exposing File Browser via Nginx Proxy Manager

With the web Docker network shared between NPM and this stack:

In NPM → Proxy Hosts → Add:
- Domain: e.g. files.kamath.cloud
- Scheme: http
- Forward Hostname/IP: filebrowser
- Forward Port: 80
- Network: web
- SSL: your usual Let’s Encrypt setup

This uses Docker DNS to reach filebrowser on the shared network and avoids mapping host ports.[

If you save this as a README next to docker-compose.yml, it should be enough context to rebuild/debug the entire setup later without re‑figuring the permission and mount logic.

7. Option Exposing Conf.d also to File Browser

You can mount ./conf.d alongside ./www in File Browser so you can edit nginx vhost configs directly from the web UI.

Step 1: Update docker-compose.yml
Add another volume to the filebrowser service:

  filebrowser:
    image: filebrowser/filebrowser:latest
    container_name: filebrowser
    restart: unless-stopped
    volumes:
      - ./www:/srv/www                      # websites under /srv/www
      - ./conf.d:/srv/conf.d                # nginx configs under /srv/conf.d
      - ./filebrowser/database:/database
      - ./filebrowser/config:/config
    networks:
      - web
    expose:
      - "80"

The key change:

Each mount creates a top-level folder in /srv (File Browser's webroot).
You'll see www and conf.d as two separate folders when you open File Browser.
Both are read/write from the container perspective.

Apply:

docker compose up -d filebrowser 
docker logs filebrowser | head    # should be clean

Then in File Browser's web UI, you'll navigate:

/srv/www/mysite.com/ → edit HTML/PHP files
/srv/conf.d/ → edit nginx vhost .conf files directly
After editing an nginx config in File Browser, restart nginx to apply changes:

docker compose exec nginx-webserver nginx -t      # test config syntax
docker compose restart nginx-webserver             # reload

Permissions for conf.d

Make sure conf.d has the same ownership/perms as www:

cd /root/webserver
chown -R your_user:www-data conf.d/
find conf.d/ -type d -exec chmod 755 {} \;
find conf.d/ -type f -exec chmod 644 {} \;

Or if you tightened to a specific uid:gid (e.g., 1001:1001), apply the same:

chown -R 1001:1001 conf.d/
find conf.d/ -type d -exec chmod 755 {} \;
find conf.d/ -type f -exec chmod 644 {} \;

This way File Browser can read/edit configs, and nginx can read them when it starts.

📌 Updating FileBrowser & Restarting Nginx (Docker)

Below is the exact sequence I used when updating the FileBrowser container and validating Nginx configuration inside my Docker-based web server stack.

# navigate to the docker webserver directory 
cd ~/webserver/  
# always back up before editing 
cp docker-compose.yml docker-compose.yml.backup  
# edit compose file if required 
nano docker-compose.yml  
# start or update the FileBrowser container 
docker compose up -d filebrowser

Expected output:

[+] Running 1/1  
✔ Container filebrowser  Started

You can check the logs to ensure it launched correctly:
docker logs filebrowser | head
Sample log output:

Using config file: /config/settings.json 
Using database: /database/filebrowser.db 
Listening on port 80

🔍 Validate Nginx Configuration

Run a config syntax check:
docker compose exec nginx-webserver nginx -t
Expected response:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok 
nginx: configuration file /etc/nginx/nginx.conf test is successful

Then restart Nginx:
docker compose restart nginx-webserver
Output:

[+] Restarting  
✔ Container nginx-webserver  Started

✔️ Notes

Always back up docker-compose.yml before changes.
Viewing only the first few lines of logs is enough to confirm container health.
Avoid exposing container ports publicly without a reverse proxy + SSL.

🔐 Security Considerations

For production stacks:

Component	Recommendation
FileBrowser	Route through Nginx Proxy Manager, enforce login, enable HTTPS
Docker logs	Avoid publishing full logs containing IPs/usernames
SSH	Do not operate daily work as `root`; use a sudo user
Backups	Keep versioned backups before any compose edits