| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| computing:filebrowser [2025/12/09 05:34] – oemb1905 | computing:filebrowser [2025/12/13 06:18] (current) – oemb1905 |
|---|
| ------------------------------------------- | ------------------------------------------- |
| * **Navidrome Setup** | * **Setting up a secure & public-facing Filebrowser instance** |
| * **oemb1905** | * **oemb1905** |
| * **filebrowser-pub** | * **filebrowser-pub** |
| This tutorial is for Debian Trixie users seeking to set up a secure and public-facing [[https://filebrowser.org/|Filebrowser]] instance. This is to assist with uploading and managing music/media on Navidrome, Jellyfin, and other similar instances. Do not proceed with this tutorial until you've learned how to set up a public facing VM/VPS and harden it appropriately. If you have not done that, start with [[https://wiki.haacksnetworking.org/doku.php?id=computing:apachesurvival|Apache Survival]]. So long as that's in place, you can safely begin. You can install Filebrowser manually, or use their automated bash script. I chose the latter. Make sure to verify the checksums and code before using the pipe-to-bash approach like me: | This tutorial is for Debian Trixie users seeking to set up a secure and public-facing [[https://filebrowser.org/|Filebrowser]] instance. This is to assist with uploading and managing music/media on Navidrome, Jellyfin, and other similar instances. Do not proceed with this tutorial until you've learned how to set up a public facing VM/VPS and harden it appropriately. If you have not done that, start with [[https://wiki.haacksnetworking.org/doku.php?id=computing:apachesurvival|Apache Survival]]. So long as that's in place, you can safely begin. You can install Filebrowser manually, or use their automated bash script. I chose the latter. Make sure to verify the checksums and code before using the pipe-to-bash approach like me: |
| |
| curl -fsSL https://raw.githubusercontent.com/filebrowser/get/master/get.sh | bash | curl -fsSL https://raw.githubusercontent.com/filebrowser/get/master/get.sh | bash |
| | sudo mkdir -p /var/lib/filebrowser |
| | sudo chown -R filebrowser:filebrowser /var/lib/filebrowser |
| | sudo chmod 755 /var/lib/filebrowser |
| | adduser navidrome filebrowser |
| | adduser jellyfin filebrowser |
| |
| The system will give you an auto-generated user and password upon completion of the installer. Let's change that before we proceed: | The system will give you an auto-generated user and password upon completion of the installer. Let's change that before we proceed: |
| Once the dedicated user is created, let's create the systemd unit to control starting/stopping the service. Let's create a unit file here ''sudo nano/etc/systemd/system/filebrowser.service'' and drop these contents inside: | Once the dedicated user is created, let's create the systemd unit to control starting/stopping the service. Let's create a unit file here ''sudo nano/etc/systemd/system/filebrowser.service'' and drop these contents inside: |
| |
| ``` | <code bash> |
| [Unit] | [Unit] |
| Description=File Browser | Description=File Browser |
| [Install] | [Install] |
| WantedBy=multi-user.target | WantedBy=multi-user.target |
| ``` | </code> |
| |
| Once that's in place, load the unit and start the service: | Once that's in place, load the unit and start the service: |
| sudo setfacl -R -m u:filebrowser:rwx /opt/navidrome/music | sudo setfacl -R -m u:filebrowser:rwx /opt/navidrome/music |
| sudo setfacl -R -m d:u:filebrowser:rwx /opt/navidrome/music | sudo setfacl -R -m d:u:filebrowser:rwx /opt/navidrome/music |
| | |
| | UPDATE: This is actually overkill. You can simply: |
| | sudo chown -R filebrowser:navidrome /opt/navidrome |
| | |
| | Bear in mind, however, that new files will be owned by filebrowser:filebrowser, but since you added navidrome and/or jellyfin to the filebrowser group up above ... you are covered. Nothing else is required. Filebrowser owns the directory and is behind SQL-lite and the authorized user and navidrome can read via the group privs. |
| |
| This assumes ''/opt/navidrome/music'' is already established and running. If not, then consult the [[https://wiki.haacksnetworking.org/doku.php?id=computing:navidrome|Navidrome]] tutorial first. The ACL above gives every current file read and write access (first stanza) and all future users read and write access (second stanza). At this time, filebrowser is already running, but behind port 8080. Now, one could simply access it with ''http://domain:com:8080'' but that won't be TLS secured and is just kind of janky. So, for these cases, we create a reverse proxy that sits facing the public and receiving requests, and then pushes incoming requests upstream to the filebrowser service running locally on port 8080. To do that, let's first edit ''/etc/apache2/000-default.conf'' and edit the ServerName to ''domain.com'', change the web root to ''/var/www/domain.com/public_html'' and leave everything else as is. Restart the service with ''systemctl restart apache2'' and then let's create a Let's Encrypt cert on the thusly adjusted default virtual host: | This assumes ''/opt/navidrome/music'' is already established and running. If not, then consult the [[https://wiki.haacksnetworking.org/doku.php?id=computing:navidrome|Navidrome]] tutorial first. The ACL above gives every current file read and write access (first stanza) and all future users read and write access (second stanza). At this time, filebrowser is already running, but behind port 8080. Now, one could simply access it with ''http://domain:com:8080'' but that won't be TLS secured and is just kind of janky. So, for these cases, we create a reverse proxy that sits facing the public and receiving requests, and then pushes incoming requests upstream to the filebrowser service running locally on port 8080. To do that, let's first edit ''/etc/apache2/000-default.conf'' and edit the ServerName to ''domain.com'', change the web root to ''/var/www/domain.com/public_html'' and leave everything else as is. Restart the service with ''systemctl restart apache2'' and then let's create a Let's Encrypt cert on the thusly adjusted default virtual host: |
| This will create another virtual host at ''000-default-le.conf'' or something similar. It will be automatically activated along with ''000-default.conf'' by default. But, this is serving requests from ''/var/www/domain.com/public_html'', and so the upstream filebrowser service is entirely ignored. But/and, the dirty work of creating the TLS cert is now done, so we can simply drop in some replacement configurations into both vhosts and restart the apache2 service and everything will automagically work. Open ''nano /etc/apache2/sites-available/000-default.conf'' and drop this inside: | This will create another virtual host at ''000-default-le.conf'' or something similar. It will be automatically activated along with ''000-default.conf'' by default. But, this is serving requests from ''/var/www/domain.com/public_html'', and so the upstream filebrowser service is entirely ignored. But/and, the dirty work of creating the TLS cert is now done, so we can simply drop in some replacement configurations into both vhosts and restart the apache2 service and everything will automagically work. Open ''nano /etc/apache2/sites-available/000-default.conf'' and drop this inside: |
| |
| ``` | <code bash> |
| <VirtualHost *:80> | <VirtualHost *:80> |
| ServerName upload.gnulinux.studio | ServerName upload.gnulinux.studio |
| RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [L,R=301] | RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [L,R=301] |
| </VirtualHost> | </VirtualHost> |
| | </code> |
| |
| Now, let's do the same trick with the https virtual host. Open up ''nano /etc/apache2/sites-available/000-default-le.conf'' and drop this inside: | Now, let's do the same trick with the https virtual host. Open up ''nano /etc/apache2/sites-available/000-default-le.conf'' and drop this inside: |
| |
| ``` | <code bash> |
| <VirtualHost *:443> | <VirtualHost *:443> |
| ServerName upload.gnulinux.studio | ServerName upload.gnulinux.studio |
| RewriteRule ^/?(.*) ws://127.0.0.1:8080/$1 [P,L] | RewriteRule ^/?(.*) ws://127.0.0.1:8080/$1 [P,L] |
| </VirtualHost> | </VirtualHost> |
| | </code> |
| |
| Once this is done, you should be good to go. Make sure that: | Once this is done, you should be good to go. Make sure that: |
| If you need more guidance, see the Apache Survival Tutorial already linked at the top. If you need help with mpm_event and fpm, use my [[https://wiki.haacksnetworking.org/doku.php?id=computing:selfhostedwp|WordPress]] tutorial. The only other thing you can optionally do is setup a rule to stop repeat brute-force attackers on Filebrowser's auth mechanism. This is optional, but here's a recipe I got off Reddit and adjusted. Open up ''/etc/fail2ban/jail.d/filebrowser.conf'' and create the jail: | If you need more guidance, see the Apache Survival Tutorial already linked at the top. If you need help with mpm_event and fpm, use my [[https://wiki.haacksnetworking.org/doku.php?id=computing:selfhostedwp|WordPress]] tutorial. The only other thing you can optionally do is setup a rule to stop repeat brute-force attackers on Filebrowser's auth mechanism. This is optional, but here's a recipe I got off Reddit and adjusted. Open up ''/etc/fail2ban/jail.d/filebrowser.conf'' and create the jail: |
| |
| ``` | <code bash> |
| [filebrowser] | [filebrowser] |
| enabled = true | enabled = true |
| bantime = 3600 | bantime = 3600 |
| action = iptables-allports[name=filebrowser] | action = iptables-allports[name=filebrowser] |
| ``` | </code> |
| |
| After the jail is established, we need to create the filter that the jail leverages to decide on whether it bans the request. To do that, open up ''/etc/fail2ban/filter.d/filebrowser.conf'' and drop the filter rules in it: | After the jail is established, we need to create the filter that the jail leverages to decide on whether it bans the request. To do that, open up ''/etc/fail2ban/filter.d/filebrowser.conf'' and drop the filter rules in it: |
| |
| ``` | <code bash> |
| [INCLUDES] | [INCLUDES] |
| before = common.conf | before = common.conf |
| failregex = /api/login: 403 <HOST> .* | failregex = /api/login: 403 <HOST> .* |
| ignoreregex = | ignoreregex = |
| ``` | </code> |
| |
| Make sure to adjust bantime, maxretry, and findtime to your preferences. Also, apache-auth's default jail is not designed for reverse proxies. So, let's create one more jail+filter to block repeat offenders against the proxy, which will trigger a 401 and/or 403 due to them trying to access something that does not exist. Let's open up the jail file ''/etc/fail2ban/jail.d/apache-auth.conf'' and drop this inside: | Make sure to adjust bantime, maxretry, and findtime to your preferences. Also, apache-auth's default jail is not designed for reverse proxies. So, let's create one more jail+filter to block repeat offenders against the proxy, which will trigger a 401 and/or 403 due to them trying to access something that does not exist. Let's open up the jail file ''/etc/fail2ban/jail.d/apache-auth.conf'' and drop this inside: |
| |
| ``` | <code bash> |
| [apache-auth] | [apache-auth] |
| enabled = true | enabled = true |
| bantime = 3600 | bantime = 3600 |
| action = iptables-allports[name=apache-auth] | action = iptables-allports[name=apache-auth] |
| ``` | </code> |
| |
| Now, for the filter, let's open ''/etc/fail2ban/filter.d/apache-auth.conf'' and drop the following inside: | Now, for the filter, let's open ''/etc/fail2ban/filter.d/apache-auth.conf'' and drop the following inside: |
| |
| ``` | <code bash> |
| [Definition] | [Definition] |
| failregex = ^<HOST> -.*"(GET|POST|HEAD).* 401 | failregex = ^<HOST> -.*"(GET|POST|HEAD).* 401 |
| ^<HOST> -.*"(GET|POST|HEAD).* 403 | ^<HOST> -.*"(GET|POST|HEAD).* 403 |
| ignoreregex = | ignoreregex = |
| ``` | </code> |
| |
| This creates a separate jail for common errors brute-forcers will receive when they are trying to access your instance's directories etc. Restart the service ''systemctl restart fail2ban'' and you should be good to go. If you need help, hit me up on [[https://matrix.to/#/@haacksnetworking:gnulinux.club|Matrix]]; I'll be happy to help! | This creates a separate jail for common errors brute-forcers will receive when they are trying to access your instance's directories etc. Restart the service ''systemctl restart fail2ban'' and you should be good to go. If you need help, hit me up on [[https://matrix.to/#/@haacksnetworking:gnulinux.club|Matrix]]; I'll be happy to help! |
| Happy Hacking !!! | Happy Hacking !!! |
| |
| --- //[[alerts@haacksnetworking.org|oemb1905]] 2025/12/09 05:10// | --- //[[alerts@haacksnetworking.org|oemb1905]] 2025/12/11 16:14// |
