SecureAnyCloud
Deployment guide

HFS

Overview

This guide covers the deployment and configuration of HFS HTTP File Server on Ubuntu 24.04 on Azure, using SecureAnyCloud 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. A full admin panel manages 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). It runs HFS 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, and 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. Behind a reverse proxy, that behaviour would expose the admin panel to every visitor. This image disables it (localhost_admin: false), so an administrator login is always required.

The image also gates the shared folder to logged-in accounts only, so there is no anonymous access, and it generates a unique administrator credential on each virtual machine's first boot. HFS stores only a one-way SRP hash of the password, and 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 you get:

  • HFS 3.2.1 from the official prebuilt self-contained binary, run under systemd as the unprivileged hfs system user
  • HFS bound to loopback only (127.0.0.1:8080), so it is never exposed directly to the network
  • nginx terminating TLS on :443 and reverse-proxying to HFS, with HSTS, 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, and 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 that 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 cloud integration and SSH key injection
  • 24/7 SecureAnyCloud 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 that allows 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
1

Deploy from the Azure Portal

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

Choose your subscription, resource group and region.

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

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

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

2

Deploy from the Azure CLI

Deploy the image from the command line and restrict SSH to your management network. Replace the example values with your own, and then run the commands:

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:hfs-ubuntu-24-04:default:latest
az vm create \
  --resource-group my-resource-group \
  --name hfs \
  --image sac1647283583153:hfs-ubuntu-24-04:default:latest \
  --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>/.

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 and writes them to a root-only file. Read the file 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 the file secret. The server stores only a one-way SRP hash of the password, never the plain text.

4

Sign in to your file server

Browse to https://<vm-ip>/. The certificate is self-signed per VM, so your browser shows a certificate warning the first time. Accept the warning 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.

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

5

Browse, download and upload files

Open the files folder to see its contents. The image ships a WELCOME.txt starter file so that the folder is not empty. From here you can download individual files, or select several and download them as a single zip archive. As the admin account, you can 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 appear in the browser immediately.

6

Open the admin panel

Open the admin panel at https://<vm-ip>/~/admin. It opens on the Home page, which confirms that the server is working. The sidebar lists Shared files, Accounts, Options, Internet, Monitoring, Logs, Plugins and more. You manage everything about the server from here.

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, and then set who can read, see, upload or delete on each one.

The available values are anyone, any logged-in account, admins only, or a named list of accounts. You can therefore mix public download folders with private ones.

Create additional users under Accounts, give each user 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.

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, and an unauthenticated file listing is refused. An authenticated request lists the shared folder and reaches the admin API:

sudo /usr/local/bin/hfs-selftest
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:

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 approach 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.

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. The config.yaml file 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 reachable only 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. Sign in only over HTTPS.

Support

This image is backed by 24/7 SecureAnyCloud support with a guaranteed 24 hour response SLA. Contact sales@secureanycloud.com for assistance.

HFS is open source software distributed under the GNU General Public License v3.0, and it is free. The SecureAnyCloud charge covers packaging, hardening, security patching, image maintenance and support.

Deploy on Azure

Launch HFS HTTP File Server on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Deploy on Azure