$ $

field notes

Storage day on the Proxmox box

A fresh install on a 500GB SATA SSD, a \ 1TB NVMe sitting idle in the same machine, and a Synology a\ lready humming on the network. Here is the full build log: \ the repo error nobody warns you about anymore, ZFS on the N\ VMe, NFS back to the NAS for ISOs, and every small thing th\ at almost went wrong along the way.

$ $

$ proxmox ve, latest release$ zfs · nfs · macos$ casula homelab$

$ $

$ root@pve: ~$

root@pve:\ ~# apt update$ Error: The list of sources could not be \ read.$ # fresh install, day one, before a si\ ngle package has updated\

$ $

$ 01$

The repo error before anything else

Every fresh Proxmox install ships with the enterpris\ e repository switched on by default, and that repo is gated\ behind a paid subscription key. Try to update without one \ and apt refuses outright. Nothing wrong with the install, t\ he box is just pointed at a door it doesn't have a key for.\

The fix that's all over older guides, c\ ommenting out a line in a .list file, doesn't apply on the \ latest release. Proxmox moved its apt sources to the deb822\ format, so the enterprise repo now lives in its own .sourc\ es file with a structured set of fields instead of one line\ .

Checking what was actually there first:

$ $

/etc/apt/sources.list.d/pve-enterprise.sources

Types: deb$ URIs: https://enterprise.proxmox.com/debian/pve$ Suites: trixie$ Components: pve-enterprise$ Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg<\ /div>$

$ $

Disabling it is one line, appended rather than comme\ nted out, since that's how the new format expects to be swi\ tched off:

$ $

root@pve: ~

root@pve:\ ~# echo 'Enabled: false' >> /etc/apt/sources.list.d/\ pve-enterprise.sources

$ $

Then a new file for the free, no subscription reposi\ tory, written in the same field based style:

$ $

/etc/apt/sources.list.d/pve-no-subscription.sources<\ /span>

Types: deb$ URIs: http://download.proxmox.com/debian/pve$ Suites: trixie$ Components: pve-no-subscription$ Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg<\ /div>$

$ $

And the update that should have run the first time:<\ /p>$ $

root@pve: ~

root@pve:\ ~# apt update && apt full-upgrade -y$ Reading package lists... Done$ ...packages upgraded, kernel included

Full upgrade rather than a plain upgrad\ e matters here. A plain upgrade holds back anything that ne\ eds a new dependency, and on Proxmox that usually means the\ kernel and the pve manager packages get left behind.

$ $

$ 02$

Giving the NVMe to ZFS

$ $

1TB NVMe, previously a Windows data drive\ , fully idle going into this

$ $

Before anything gets wiped, this box turned out to h\ ave more drives in it than expected. Worth the five seconds\ it takes to check:

$ $

root@pve: ~

root@pve:\ ~# lsblk$ sda 1.8T disk (spinner, not in us\ e)$ sdb 447G disk (the proxmox os drive, leave alone)$ sdc 28.7G disk (usb installer media, removable)$ nvme1n1 466G disk (existing windows install)$ nvme0n1 932G disk (the target — had old ntfs data on it\ )

One of those NVMe drives already had an\ NTFS partition labeled from a previous build. Mounted it r\ ead only first with ntfs-3g, eyeballed the contents, confir\ med nothing on it mattered, then wiped.

$ $

Clearing the old partition table and any leftover fi\ lesystem signatures:

$ $

root@pve: ~

root@pve:\ ~# wipefs -a /dev/nvme0n1p1$ root@pve:~# wipefs -a /dev/nvme\ 0n1p2$ root@pve:~# wipefs -a /dev/nvme\ 0n1

$ $

Then the ZFS pool itself, aligned to 4K sectors and \ with trim turned on so the drive can reclaim space properly\ over time:

$ $

root@pve: ~

root@pve:\ ~# zpool create -o ashift=12 vmdata /dev/nvme0n1$ root@pve:~# zpool set autotrim=\ on vmdata

$ $

And registering it as usable Proxmox storage, availa\ ble to both VM disks and container root filesystems:

$ $

root@pve: ~

root@pve:\ ~# pvesm add zfspool vmdata --pool vmdata --content \ images,rootdir$ root@pve:~# pvesm status$ vmdata zfspool active 900G avail\ able

$ $

$ 03$

NFS to the Synology, for ISOs

$ $

Synology, two bays, already on the networ\ k

$ $

NFS over CIFS for this one, since both ends are Linu\ x underneath and it skips the username and password dance e\ ntirely, just IP based permissions. On the Synology side: e\ nable the NFS service, then on the shared folder itself, ad\ d an NFS permission rule scoped to the Proxmox node's IP.$ $

Back on Proxmox, finding the exact export path rathe\ r than guessing it:

$ $

root@pve: ~

root@pve:\ ~# showmount -e 192.168.0.13$ Export list for 192.168.0.13:$ /volume2/Virtual 192.168.0.66

$ $

That second column is worth a glance too, it's the h\ ost allow list. This export was locked to one IP, which mad\ e sense, that was the Proxmox box. Registering the storage:\

$ $

root@pve: ~

root@pve:\ ~# pvesm add nfs synology-isos --server 192.168.0.13\ --export /volume2/Virtual --content iso

$ $

The share showed up fine in Proxmox, bu\ t ISOs sitting at the share root didn't appear anywhere in \ the UI. Proxmox doesn't browse the whole share, it only loo\ ks inside fixed subfolders, template/iso for ISOs, template\ /cache for templates, dump for backups.

$ $

The fix was just moving them into the folder Proxmox\ actually checks:

$ $

root@pve: ~

root@pve:\ ~# mkdir -p /mnt/pve/synology-isos/template/iso$ root@pve:~# mv /mnt/pve/synolog\ y-isos/*.iso /mnt/pve/synology-isos/template/iso/

Refreshed the ISO Images tab in the GUI and every fi\ le appeared immediately. Anything dropped into that same fo\ lder from now on, Finder, File Station, doesn't matter, sho\ ws up automatically.

$ $

$ 04$

Mounting the same share from macOS

$ $

Useful for browsing the same ISO folder without goin\ g near the Proxmox shell. macOS has an NFS client built in,\ no extra software needed, but the first attempt threw a lo\ cking error that's worth knowing about ahead of time:

$ $

dominicgenn@macm2prowifi ~

% \ sudo mount -t nfs -o resvport,rw 192.168.0.13:/volume2/Virt\ ual /Volumes/isos$ mount_nfs: can't mount with remote locks\ when server is not running rpc.statd

$ $

Synology's NFSv3 implementation doesn't run the lock\ ing service macOS expects by default. Cleanest fix for a re\ ad mostly ISO share is just to skip locking entirely on the\ mount:

$ $

dominicgenn@macm2prowifi ~

% \ sudo mkdir -p /Volumes/isos$ % sudo mount -t nfs -o resvport\ ,rw,nolocks 192.168.0.13:/volume2/Virtual /Volumes/isos$ mounted clean, no errors

The host allow list mattered here too. \ The Mac needed its own NFS permission entry added on the Sy\ nology side before any of this would even connect, since th\ e original rule only allowed the Proxmox node's IP.

$ $

What I'd tell myself before starting

Run lsblk and look at every single disk before wi\ ping anything. This box had a spinner, a USB installer, and\ a second NVMe with a live Windows install on it that never\ got mentioned out loud until lsblk forced the conversation\ .
The latest Proxmox release uses deb822 .sources f\ iles for apt. The old trick of commenting out a line in a .\ list file is for older versions and won't touch the new for\ mat at all.
Proxmox only looks inside template/iso, template/\ cache, and dump on a storage mount, never the share root. F\ iles sitting anywhere else are invisible to the UI even tho\ ugh they're really there.
NFS permissions on Synology are locked per host I\ P. Every device that needs to mount the share, Proxmox, a M\ ac, anything else, needs its own entry in that list.
macOS and Synology's NFSv3 don't agree on locking\ out of the box. Add nolocks to the mount options, or switc\ h to NFSv4, and the rpc.statd error disappears.

$ $ $ $