WebDAV Server

Search the Marketplace for WebDAV Server on Ubuntu 24.04 and choose your VM size. Attach a network security group (NSG) that allows TCP 22 (SSH) from your management network and TCP 443 (HTTPS WebDAV) from the clients that will use the share.

Basic Auth and TLS are enforced, so the server is safe to expose to your clients. Still, restrict the source ranges to networks you control.

RG="webdav-prod"; LOCATION="eastus"; VM_NAME="webdav-01" IMAGE_URN="sac1647283583153:webdav-server-ubuntu-24-04:default:latest" SSH_KEY="$(cat ~/.ssh/id_rsa.pub)" az group create --name "$RG" --location "$LOCATION" az network vnet create -g "$RG" --name wd-vnet --address-prefix 10.90.0.0/16 --subnet-name wd-subnet --subnet-prefix 10.90.1.0/24 az network nsg create -g "$RG" --name wd-nsg az network nsg rule create -g "$RG" --nsg-name wd-nsg --name allow-ssh --priority 100 \
  --source-address-prefixes "<your-mgmt-cidr>" --destination-port-ranges 22 --access Allow --protocol Tcp az network nsg rule create -g "$RG" --nsg-name wd-nsg --name allow-webdav --priority 110 \
  --source-address-prefixes "<your-mgmt-cidr>" --destination-port-ranges 443 --access Allow --protocol Tcp
# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:webdav-server-ubuntu-24-04:default:latest
az vm create -g "$RG" --name "$VM_NAME" --image "$IMAGE_URN" \
  --size Standard_B2s --storage-sku StandardSSD_LRS \
  --admin-username azureuser --ssh-key-values "$SSH_KEY" \
  --vnet-name wd-vnet --subnet wd-subnet --nsg wd-nsg --public-ip-sku Standard

ssh azureuser@<vm-ip>

WebDAV Server serves HTTPS on :443. Every request requires authentication, so an unauthenticated call returns 401.

sudo systemctl start webdav 2>/dev/null || true
sudo systemctl is-active webdav ss -tln | grep ':443' echo "unauthenticated / -> HTTP $(curl -sk -o /dev/null -w '%{http_code}' https://127.0.0.1/)"

The output shows the service active, the listening socket on :443, and HTTP 401 from the unauthenticated call. The 401 confirms that authentication is enforced.

The image generated a username and password on this VM's first boot and stored them in a root-only file. The server configuration keeps the password only as a bcrypt hash. Read the credentials and keep them secret. Then confirm that the per-VM credential authenticates and that an unauthenticated request does not.

sudo cat /root/webdav-info.txt
U=$(sudo grep '^WEBDAV_USER=' /root/webdav-info.txt | cut -d= -f2-)
P=$(sudo grep '^WEBDAV_PASSWORD=' /root/webdav-info.txt | cut -d= -f2-)
echo "unauthenticated -> HTTP $(curl -sk -o /dev/null -w '%{http_code}' https://127.0.0.1/)"
echo "authenticated -> HTTP $(curl -sk -o /dev/null -w '%{http_code}' -u "$U:$P" https://127.0.0.1/)"

The info note holds WEBDAV_USER, WEBDAV_PASSWORD and the WebDAV URL. It is owned by root:root with mode 0600. The server returns 401 without the credential and 2xx with it. The per-VM TLS certificate at /etc/webdav/tls/cert.pem encrypts the transport.

Upload a file with an authenticated PUT. Fetch it straight back and confirm that it matches byte for byte. Then list the directory with PROPFIND. A WebDAV client does exactly this under the hood.

U=$(sudo grep '^WEBDAV_USER=' /root/webdav-info.txt | cut -d= -f2-)
P=$(sudo grep '^WEBDAV_PASSWORD=' /root/webdav-info.txt | cut -d= -f2-) BLOB="hello from WebDAV Server at $(date -u +%FT%TZ)" printf '%s' "$BLOB" | curl -sk -u "$U:$P" -T - "https://127.0.0.1/demo.txt" -o /dev/null -w 'PUT /demo.txt -> HTTP %{http_code}\n'
GOT=$(curl -sk -u "$U:$P" "https://127.0.0.1/demo.txt") [ "$GOT" = "$BLOB" ] && echo "GET /demo.txt -> byte for byte match" || echo "GET /demo.txt -> MISMATCH" echo "PROPFIND / -> HTTP $(curl -sk -o /dev/null -w '%{http_code}' -u "$U:$P" -X PROPFIND -H 'Depth: 1' https://127.0.0.1/)" echo "unauthenticated GET /demo.txt -> HTTP $(curl -sk -o /dev/null -w '%{http_code}' https://127.0.0.1/demo.txt)" curl -sk -u "$U:$P" -X DELETE "https://127.0.0.1/demo.txt" -o /dev/null

The PUT returns 201. The authenticated GET returns the identical file. PROPFIND returns 207 Multi-Status, which is the directory listing. An unauthenticated GET of the same path returns 401, so content is never served without the credential.

Use the username and password from Step 5 and the server address https://<vm-ip>/. The certificate is self-signed, so clients prompt you to trust it on first connect. See Step 8 to install a trusted certificate.

Windows (File Explorer): open File Explorer, right-click This PC, choose Map network drive, and enter https://<vm-ip>/ as the folder. Windows prompts for the username and password. You can also use the command line:

net use * https://<vm-ip>/ /user:<webdav-username> <webdav-password>

macOS (Finder): in Finder, choose Go -> Connect to Server (Command-K) and enter https://<vm-ip>/. Supply the username and password when prompted.

Linux (davfs2): install davfs2 and mount the share:

sudo apt-get install -y davfs2
sudo mount -t davfs https://<vm-ip>/ /mnt/webdav

curl (any platform): upload, download and list from scripts:

curl -u <webdav-username>:<webdav-password> -T ./report.pdf https://<vm-ip>/report.pdf
curl -u <webdav-username>:<webdav-password> https://<vm-ip>/report.pdf -o report.pdf
curl -u <webdav-username>:<webdav-password> -X PROPFIND -H 'Depth: 1' https://<vm-ip>/

The server ships with a per-VM self-signed certificate. It encrypts traffic, but clients do not trust it out of the box, so they prompt on first connect. For a smoother experience, either distribute the self-signed certificate to your clients as a trusted root, or replace it with a certificate from a public CA.

To use a real certificate from Let's Encrypt, you need a public DNS name that points at the VM and TCP 80 reachable. Install certbot, obtain a certificate for <your-domain>, point the config at it, and restart the service:

sudo apt-get install -y certbot
sudo certbot certonly --standalone -d <your-domain> --agree-tos -m <your-email> -n sudo sed -i "s#^cert:.*#cert: /etc/letsencrypt/live/<your-domain>/fullchain.pem#" /etc/webdav/config.yml
sudo sed -i "s#^key:.*#key: /etc/letsencrypt/live/<your-domain>/privkey.pem#" /etc/webdav/config.yml
sudo systemctl restart webdav

Clients then connect to https://<your-domain>/ without a certificate warning.

The server configuration lives at /etc/webdav/config.yml. It defines the listening address and port, the served directory, the TLS certificate, and the users with their permissions. Permissions combine the letters C (create), R (read), U (update) and D (delete). The per-VM admin user is granted CRUD.

To add a read-only user or a second full-access user, generate a bcrypt hash and add a users entry, then restart the service. Never store a plaintext password in the config:

# generate a bcrypt hash for a new password (never store plaintext in the config) htpasswd -nbBC 10 reader "<new-password>"
# add a users: entry to /etc/webdav/config.yml with permissions: R for read only, then:
sudo systemctl restart webdav

The served directory lives on the OS disk under /var/lib/webdav/data. Inspect it and its disk usage:

ls -ld /var/lib/webdav/data du -sh /var/lib/webdav/data 2>/dev/null df -h /var/lib/webdav

To grow capacity, attach a dedicated data disk and mount it at /var/lib/webdav/data, preserving webdav ownership. The served content then lives on the larger volume.

In the AWS Marketplace, search for WebDAV Server by SecureAnyCloud. Choose Continue to Subscribe, then Continue to Configuration and Continue to Launch. Select your instance type (m5.large is a good default), your VPC and subnet, and your key pair. Attach a security group that allows:

• TCP 22 (SSH) from your management network only
• TCP 443 (HTTPS WebDAV) from the clients that will use the share

Basic Auth and TLS are enforced, so the server is safe to expose to your clients. Still, restrict the source ranges to networks you control.

AMI_ID="<ami-id>"
# the WebDAV Server AMI id for your region KEY_NAME="<your-key-pair>" SUBNET_ID="<subnet-id>"
# a public subnet REGION="us-east-1"
# Security group: SSH from your management CIDR, WebDAV (443) from your clients
SG_ID=$(aws ec2 create-security-group --region "$REGION" \
  --group-name webdav-sg --description "WebDAV Server" \
  --vpc-id <vpc-id> --query GroupId --output text)
aws ec2 authorize-security-group-ingress --region "$REGION" --group-id "$SG_ID" \
  --protocol tcp --port 22 --cidr <your-mgmt-cidr>
aws ec2 authorize-security-group-ingress --region "$REGION" --group-id "$SG_ID" \
  --protocol tcp --port 443 --cidr <your-clients-cidr>
aws ec2 run-instances --region "$REGION" \
  --image-id "$AMI_ID" --instance-type m5.large \
  --key-name "$KEY_NAME" --subnet-id "$SUBNET_ID" \
  --security-group-ids "$SG_ID" \
  --metadata-options "HttpTokens=required" \
  --associate-public-ip-address \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=webdav-01}]'

The instance uses IMDSv2 (HttpTokens=required). The first-boot service reads the instance metadata with a token to resolve the server URL.

ssh -i your-key.pem ubuntu@<public-ip>

WebDAV Server serves HTTPS on :443. Every request requires authentication, so an unauthenticated call returns 401.

sudo systemctl is-active webdav
sudo ss -tln | grep ':443' /usr/local/bin/webdav version echo "unauthenticated / -> HTTP $(curl -sk -o /dev/null -w '%{http_code}' https://127.0.0.1/)"

The output shows the service active, the listening socket on :443, the webdav version, and HTTP 401 from the unauthenticated call. The 401 confirms that authentication is enforced.

The image generated a username and password on this instance's first boot and stored them in a root-only file. The server configuration keeps the password only as a bcrypt hash. Read the credentials and keep them secret. Then confirm that the per-instance credential authenticates and that an unauthenticated request does not.

sudo cat /root/webdav-info.txt
U=$(sudo grep '^WEBDAV_USER=' /root/webdav-info.txt | cut -d= -f2-)
P=$(sudo grep '^WEBDAV_PASSWORD=' /root/webdav-info.txt | cut -d= -f2-)
echo "unauthenticated -> HTTP $(curl -sk -o /dev/null -w '%{http_code}' https://127.0.0.1/)"
echo "authenticated -> HTTP $(curl -sk -o /dev/null -w '%{http_code}' -u "$U:$P" https://127.0.0.1/)"

The info note holds WEBDAV_USER, WEBDAV_PASSWORD and the WebDAV URL. It is owned by root:root with mode 0600. The server returns 401 without the credential and 2xx with it. The per-instance TLS certificate at /etc/webdav/tls/cert.pem encrypts the transport.

Upload a file with an authenticated PUT. Fetch it straight back and confirm that it matches byte for byte. Then list the directory with PROPFIND. A WebDAV client does exactly this under the hood.

U=$(sudo grep '^WEBDAV_USER=' /root/webdav-info.txt | cut -d= -f2-)
P=$(sudo grep '^WEBDAV_PASSWORD=' /root/webdav-info.txt | cut -d= -f2-) BLOB="hello from WebDAV Server at $(date -u +%FT%TZ)" printf '%s' "$BLOB" | curl -sk -u "$U:$P" -T - "https://127.0.0.1/demo.txt" -o /dev/null -w 'PUT /demo.txt -> HTTP %{http_code}\n'
GOT=$(curl -sk -u "$U:$P" "https://127.0.0.1/demo.txt") [ "$GOT" = "$BLOB" ] && echo "GET /demo.txt -> byte for byte match" || echo "GET /demo.txt -> MISMATCH" echo "PROPFIND / -> HTTP $(curl -sk -o /dev/null -w '%{http_code}' -u "$U:$P" -X PROPFIND -H 'Depth: 1' https://127.0.0.1/)" echo "unauthenticated GET /demo.txt -> HTTP $(curl -sk -o /dev/null -w '%{http_code}' https://127.0.0.1/demo.txt)" curl -sk -u "$U:$P" -X DELETE "https://127.0.0.1/demo.txt" -o /dev/null

The PUT returns 201. The authenticated GET returns the identical file. PROPFIND returns 207 Multi-Status, which is the directory listing. An unauthenticated GET of the same path returns 401, so content is never served without the credential.

Use the username and password from Step 5 and the server address https://<public-ip>/. The certificate is self-signed, so clients prompt you to trust it on first connect. See Step 8 to install a trusted certificate.

Windows (File Explorer): open File Explorer, right-click This PC, choose Map network drive, and enter https://<public-ip>/ as the folder. Windows prompts for the username and password. You can also use the command line:

net use * https://<public-ip>/ /user:<webdav-username> <webdav-password>

macOS (Finder): in Finder, choose Go -> Connect to Server (Command-K) and enter https://<public-ip>/. Supply the username and password when prompted.

Linux (davfs2): install davfs2 and mount the share:

sudo apt-get install -y davfs2
sudo mount -t davfs https://<public-ip>/ /mnt/webdav

curl (any platform): upload, download and list from scripts:

curl -u <webdav-username>:<webdav-password> -T ./report.pdf https://<public-ip>/report.pdf
curl -u <webdav-username>:<webdav-password> https://<public-ip>/report.pdf -o report.pdf
curl -u <webdav-username>:<webdav-password> -X PROPFIND -H 'Depth: 1' https://<public-ip>/

The server ships with a per-instance self-signed certificate. It encrypts traffic, but clients do not trust it out of the box, so they prompt on first connect. For a smoother experience, either distribute the self-signed certificate to your clients as a trusted root, or replace it with a certificate from a public CA.

To use a real certificate from Let's Encrypt, you need a public DNS name that points at the instance and TCP 80 reachable. Install certbot, obtain a certificate for your-domain, point the config at it, and restart the service:

sudo apt-get install -y certbot
sudo certbot certonly --standalone -d your-domain --agree-tos -m your-email -n sudo sed -i "s#^cert:.*#cert: /etc/letsencrypt/live/your-domain/fullchain.pem#" /etc/webdav/config.yml
sudo sed -i "s#^key:.*#key: /etc/letsencrypt/live/your-domain/privkey.pem#" /etc/webdav/config.yml
sudo systemctl restart webdav

Clients then connect to https://your-domain/ without a certificate warning.

The server configuration lives at /etc/webdav/config.yml. It defines the listening address and port, the served directory, the TLS certificate, and the users with their permissions. Permissions combine the letters C (create), R (read), U (update) and D (delete). The per-instance admin user is granted CRUD.

To add a read-only user or a second full-access user, generate a bcrypt hash and add a users entry, then restart the service. Never store a plaintext password in the config:

# generate a bcrypt hash for a new password (never store plaintext in the config) htpasswd -nbBC 10 reader "<new-password>"
# add a users: entry to /etc/webdav/config.yml with permissions: R for read only, then:
sudo systemctl restart webdav

The served directory lives on the root EBS volume under /var/lib/webdav/data. Inspect it and its disk usage:

ls -ld /var/lib/webdav/data du -sh /var/lib/webdav/data 2>/dev/null df -h /var/lib/webdav

To grow capacity, attach a dedicated EBS volume and mount it at /var/lib/webdav/data, preserving webdav ownership. The served content then lives on the larger, independently resizable volume.

The served directory lives on the root EBS volume under /var/lib/webdav/data. The first-boot service generates the per-instance username, password and TLS certificate. It refreshes the webdav binary to the latest release and writes the fail-secure bootstrap marker. It then disables itself, so subsequent reboots are unaffected. The OS ships fully patched with unattended security upgrades enabled.

sudo /usr/local/bin/webdav version 2>/dev/null | head -1 systemctl is-enabled webdav-firstboot.service webdav.service ls -ld /var/lib/webdav/data export DEBIAN_FRONTEND=noninteractive;
sudo apt-get update -y >/dev/null 2>&1 echo "held packages: $(apt-mark showhold | tr '\n' ' ')[none]"