HFS HTTP File Server on Ubuntu 24.04 on Azure User Guide

Overview

This guide covers the deployment and configuration of HFS HTTP File Server on Ubuntu 24.04 on Azure using cloudimg Azure Marketplace images. HFS (HTTP File Server) is an open source, self hosted web file server. It lets you browse folders, upload with drag and drop, download files and whole folders as archives, and share content straight from a web browser, with a full admin panel for managing accounts, virtual folders and granular per folder permissions.

The image installs the pinned stable HFS 3.2.1 release from the official prebuilt self contained binary (recorded in /opt/hfs/app/VERSION) and runs it under systemd as the unprivileged hfs system user, bound to loopback only (127.0.0.1:8080). nginx is the sole network facing surface: it terminates TLS on port 443 and reverse proxies to HFS. Port 80 redirects to HTTPS.

Secure by default. Out of the box HFS ships with no account and grants admin access to anyone connecting from localhost, which behind a reverse proxy would expose the admin panel to every visitor. This image disables that behaviour (localhost_admin: false) so an administrator login is always required, gates the shared folder to logged in accounts only so there is no anonymous access, and generates a unique administrator credential on each virtual machine's first boot. HFS stores only a one way SRP hash of the password; the plain password is placed in a root only file for the administrator to read. There are no shared or default credentials, and nothing usable is baked into the image.

What is included:

• HFS 3.2.1 from the official prebuilt self contained binary and run under systemd as the unprivileged hfs system user

• HFS bound to loopback only (127.0.0.1:8080); it is never network exposed directly

• nginx terminating TLS on :443 and reverse proxying to HFS, with HSTS and sensible security headers and unlimited upload body size for large files

• Port :80 returns a 301 redirect to HTTPS for every path except an unauthenticated /healthz endpoint (HTTP 200) for load balancer probes

• A unique admin credential generated per VM on first boot; only the one way SRP hash is stored, the plain password lands in a root only file

• Admin panel access hardened (localhost_admin: false) and one trusted reverse proxy configured (proxies: 1) so real client IPs are logged

• The shared folder /srv/hfs-files gated to logged in accounts, so there is no anonymous access baked in

• A self signed TLS certificate regenerated per VM on first boot (its Subject Alternative Names include the VM public IP, hostname and 127.0.0.1); replace it with your own CA signed certificate for production

• A built in self test at /usr/local/bin/hfs-selftest that proves the authenticated file listing and admin API end to end over TLS

• Ubuntu 24.04 LTS base with the latest security patches applied at build time

• Azure Linux Agent for seamless cloud integration and SSH key injection

• 24/7 cloudimg support with a guaranteed 24 hour response SLA

Prerequisites

• An Azure subscription with permission to deploy virtual machines

• An SSH key pair for administrative access to the VM as the azureuser account

• A Network Security Group allowing inbound TCP 443 (HTTPS) and 80 (redirect) from the networks that should reach the service, and 22 (SSH) from your management network only

• A recommended size of Standard_B2s or larger

Step 1: Deploy from the Azure Portal

1. Locate the HFS HTTP File Server on Ubuntu 24.04 LTS image in the Azure Marketplace and select Create.

2. Choose your subscription, resource group and region.

3. Select a VM size (Standard_B2s or larger) and provide your SSH public key for the azureuser account.

4. On the Networking tab, allow inbound 443 and 80 from your users, and restrict 22 to your management network.

5. Review and create. When the VM is running, browse to https://<your-public-ip>/.

Step 2: Deploy from the Azure CLI

Deploy the image from the command line, restricting SSH to your management network. Replace the placeholder values with your own before running:

az vm create \
  --resource-group my-resource-group \
  --name hfs \
  --image <marketplace-image-urn> \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_rsa.pub \
  --public-ip-sku Standard

# Allow the web UI from your users and SSH from your management network only
az vm open-port --resource-group my-resource-group --name hfs --port 443 --priority 1001
az network nsg rule create --resource-group my-resource-group --nsg-name hfsNSG \
  --name allow-ssh --priority 1002 --destination-port-ranges 22 \
  --source-address-prefixes <your-mgmt-cidr> --access Allow --protocol Tcp

When the VM is running, browse to https://<public-ip>/.

Step 3: Retrieve your per instance admin credential

Access requires an HFS account login. Each VM generates its own admin username and password on first boot, written to a root only file. Read it over SSH:

ssh azureuser@<vm-ip> 'sudo cat /root/hfs-credentials.txt'

The file contains the HFS_USER, HFS_PASS and HFS_URL for this specific VM. Keep it secret. The server only ever stores a one way SRP hash of the password, never the plain text.

Step 4: Sign in to your file server

Browse to https://<vm-ip>/. Because the certificate is self signed per VM, your browser will show a certificate warning the first time; accept it to proceed (or install the per VM certificate, or place a CA signed certificate in front, as covered in Step 10). HFS then shows its login form; sign in with the username and password from Step 3.

Because the shared folder is gated to logged in accounts, there is no anonymous access: an unauthenticated request is refused. After signing in you land on the file browser, which shows the shared files folder along with a toolbar for Select, Search, Options and Zip.

Step 5: Browse, download and upload files

Open the files folder to see its contents. The image ships a WELCOME.txt starter file so the folder is not empty. From here you can download individual files, select several and download them as a single zip archive, and, as the admin account, upload new files with the Upload button or by dragging them onto the page.

Your files live on the VM at /srv/hfs-files. You can also add files to that folder directly over SSH and they will appear in the browser immediately.

Step 6: Open the admin panel

Reach the admin panel at https://<vm-ip>/~/admin. It opens on the Home page, which confirms the server is working and gives you a full sidebar: Shared files, Accounts, Options, Internet, Monitoring, Logs, Plugins and more. This is where you manage everything about the server.

Step 7: Add shared folders, accounts and permissions

Select Shared files in the admin sidebar to manage the Virtual File System. The tree shows your Home folder with the files folder inside it. Use the toolbar to add more folders from disk, then set who can read, see, upload or delete on each one. Values are: anyone, any logged in account, admins only, or a named list of accounts, so you can mix public download folders with private ones.

Create additional users under Accounts, give each their own home folder or set of permissions, and share links publicly or privately as needed. The single admin credential from Step 3 is only the starting point.

Step 8: Verify the deployment

SSH to the VM as azureuser and confirm the services are running and HFS is bound to loopback only:

systemctl is-active hfs nginx
sudo ss -tlnp | grep 8080

All services report active, and HFS listens on 127.0.0.1:8080 only. nginx is the only component exposed on :80 and :443.

Run the built in self test. It reads this VM's credential and proves the full path over TLS: the health probe answers, an unauthenticated request is refused, an unauthenticated file listing is refused, and an authenticated request lists the shared folder and reaches the admin API:

sudo /usr/local/bin/hfs-selftest

Step 9: TLS, redirect and the authentication gate

nginx terminates TLS on port 443 and redirects plain HTTP on port 80 to HTTPS. Confirm the redirect, the unauthenticated health probe, and that both the file server and its listing API require the per VM credential:

curl -s -o /dev/null -w 'port 80 -> HTTP %{http_code}\n' http://127.0.0.1/
curl -sk -o /dev/null -w 'healthz -> HTTP %{http_code}\n' https://127.0.0.1/healthz
curl -sk -o /dev/null -w 'no creds -> HTTP %{http_code}\n' https://127.0.0.1/
curl -sk -o /dev/null -w 'listing no creds -> HTTP %{http_code}\n' 'https://127.0.0.1/~/api/get_file_list?uri=/'

Port 80 returns 301 and the health endpoint returns 200. An unauthenticated request to the file server, and to the file listing API, is refused with 401, while a request carrying this VM's credential succeeds with 200. The self signed certificate is regenerated per VM on first boot, with the VM IP and hostname in its Subject Alternative Names:

Step 10: Replace the certificate for production

The per VM certificate is self signed, so browsers warn on first use. For a public deployment, put a real certificate in front. The simplest path is to point a DNS name at the VM and obtain a free certificate with Certbot:

# Point https://<your-domain> at this VM first, then:
sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d <your-domain>

Alternatively, terminate TLS at an Azure Application Gateway or a load balancer in front of the VM and forward to port 443. HFS is already configured to trust one reverse proxy (proxies: 1) so it logs the real client IP behind nginx.

Step 11: Baked version and per instance credential

The baked HFS version is recorded on the VM, alongside this instance's credential summary. The password line is redacted below; read the full value from the root only file in Step 3. Note that config.yaml stores only a one way SRP hash, never a plain text password:

cat /opt/hfs/app/VERSION
sudo cat /root/hfs-credentials.txt

Security notes

• No default login. HFS enforces its own account login and a unique admin credential is generated on each VM's first boot. Only a one way SRP hash is stored; the plain password lives in the root only /root/hfs-credentials.txt.

• No anonymous access, hardened admin. The shared folder is gated to logged in accounts, and localhost_admin is disabled so the admin panel behind the reverse proxy still requires an admin login. Nothing is exposed anonymously.

• Loopback only application. HFS binds to 127.0.0.1:8080 and is only reachable through the nginx TLS reverse proxy on :443. Keep it that way and let nginx (or a load balancer) be the sole network facing surface.

• Restrict access. Allow 443 only from the networks that need it, keep 22 restricted to your management network, and replace the self signed certificate with a CA signed one for production.

• Manage credentials in the admin panel. Change the admin password, create additional accounts and set per folder permissions under Accounts and Shared files in the admin panel, and only sign in over HTTPS.

Support

This image is backed by 24/7 cloudimg support with a guaranteed 24 hour response SLA. Contact support@cloudimg.co.uk for assistance. HFS is open source software distributed under the GNU General Public License v3.0 and is free; the cloudimg charge covers packaging, hardening, security patching, image maintenance and support.