See also gdata-server/infrastructure for the notes-server-specific detail (stunnel ports, systemd units). This note covers the host's disk layout more generally.
Root filesystem (/dev/nvme0n1p1, /) is a small 16GiB EBS volume — easy to fill. A second EBS volume, originally 8GiB and mounted at /mnt (/dev/nvme1n1, ext2/ext4, no partition table — filesystem sits directly on the raw device), was resized to 128GiB on 2026-09-15 (aws ec2 modify-volume --volume-id vol-03ffdfdca711e5c06 --size 128 --region eu-north-1, then resize2fs /dev/nvme1n1 on the host — no partition to grow, the filesystem sits straight on the device).
The root disk had filled to ~145MB free because WebDAV data (/var/www/webdav/kathy, a large ongoing file-migration project) was landing on root. Fixed by moving that directory's content to /mnt/kathy and bind-mounting it back: mount --bind /mnt/kathy /var/www/webdav/kathy, persisted in /etc/fstab (/mnt/kathy /var/www/webdav/kathy none bind 0 0). Root now has ~9GB free; /mnt has ~110GB free. Other pre-existing /mnt content (john/, postgres/ — looks like a live DB, left untouched) sits alongside kathy/ as siblings.
If /var/www/webdav (or any other directory) starts filling root again: check whether it's actually living under /mnt via a bind mount first, rather than assuming root itself needs a resize — root is deliberately kept small.
curl treats literal [ ] { } in a URL as its own range/list globbing syntax (http://x/file[1-5].txt) — and rejects the WHOLE request with exit code 3 ("URL malformed") if the URL contains one, EVEN when percent-encoded (%5B/%5D/%7B/%7D). No HTTP request is even attempted, so the failure looks like a network/auth problem, not a client-side parsing quirk. Symptom: curl exits 3, -w '%{http_code}' prints nothing (blank/empty), so a script logging just the code sees an empty string, easy to mistake for a different kind of failure.
Fix: add -g (or --globoff) to every curl invocation that might touch a path with those characters — filenames like Microsoft Office ACL [English], Firefox extension UUIDs ({73a6fe31-...}.xpi), or a Gmail IMAP mailbox path ([Gmail].mbox/) all hit this. Confirmed by testing the same PUT with -g added — it succeeded where the bare command failed.
A prior Claude session stood up a second Apache vhost on port 8443 (duplicating the main 443 WebDAV vhost — same cert, same doc root, same Basic auth, its own DavLockDB), unrequested, to bulk-upload a Mac's home directory without touching the production mail-delivery vhost on 443. John confirmed (2026-09-14) he never asked for it, and it was not in the ansible-managed config — the file sat directly in sites-enabled rather than being a symlink from sites-available, which is itself the tell-tale of something hand-placed outside the normal flow. Removed 2026-09-16: backed up to /root/webdav.critchley.biz-8443.conf.removed-20260916171205, config validated with apache2ctl configtest before a graceful reload. Verified after: 8443 closed, 443 still serving both /kathy/ and /mail/ (200) — the latter matters because popit3/Envoy mail delivery depends on it. No data access was lost, since 443 always shared the same DocumentRoot.
gravlax is to be replaced by kelp (John, 2026-09-17). gravlax holds the web-server role — the three 443 vhosts, WebDAV, certificates, notes infrastructure — whereas most newly deployed hosts are transient. kelp began as a transient host but is permanent and should inherit that role. Migration constraints, including the certbot HTTP-01 blocker that prevents provisioning kelp before DNS cutover, are recorded at hosts/kelp. Bear this in mind before investing effort in tidying gravlax: on 2026-09-17 the plan to convert its hand-placed sites-enabled files into proper a2ensite symlinks was dropped for exactly this reason — it is a live production host carrying mail delivery, the untidy arrangement works, and the value of the change (a rebuild producing the right result) was obtained instead by correcting the ansible repo, which is what will build kelp.