You install Proxmox VE 9.2, log in, run apt update, and the terminal answers with two 401 Unauthorized errors against enterprise.proxmox.com. You already know the fix: delete or comment out /etc/apt/sources.list.d/pve-enterprise.list. So you run it, and nothing changes. The errors come back, identical.
The reason is that the file is not there. Proxmox VE 9 ships its repository configuration in the deb822 .sources format, and the enterprise definitions now live in pve-enterprise.sources and ceph.sources. Every rm -f aimed at the old .list filenames succeeds silently, removes nothing, and leaves the 401 in place. This guide walks through the current procedure on a Proxmox VE 9.2 node, in both file formats, and explains which one to prefer.
Before you start
- A Proxmox VE 9.x node, freshly installed or upgraded. Examples below were run on 9.2, built on Debian 13 "Trixie".
- Root access over SSH or through the node shell.
- Outbound HTTP access to
download.proxmox.com. - About fifteen minutes, plus download time for the first
full-upgrade. - A maintenance window if the node is in production: a kernel update will be part of the upgrade, and it needs a reboot to become active.
Why the 401 appears, and why the old fix does nothing
Proxmox publishes several package repositories. The enterprise repository carries the packages that have been through the longest test cycle, and it requires a valid subscription key. The no-subscription repository carries the same packages at an earlier point in that cycle, with no key required. A test repository carries development builds.
A fresh installation is configured for the enterprise repository, by design. Without a subscription key, the server returns 401 and APT refuses the index as unsigned:
Err:4 https://enterprise.proxmox.com/debian/ceph-tentacle trixie InRelease 401 Unauthorized [IP: 185.219.221.167 443] Err:5 https://enterprise.proxmox.com/debian/pve trixie InRelease 401 Unauthorized [IP: 185.219.221.167 443] Error: The repository 'https://enterprise.proxmox.com/debian/pve trixie InRelease' is not signed. Notice: Updating from such a repository can't be done securely, and is therefore disabled by default.
Note the two distinct errors. One is the Proxmox VE repository, the other is the Ceph repository. Both are enabled out of the box, even on a node that will never run Ceph. Fixing only the first leaves you with one remaining 401 and the same refusal to update.
On Proxmox VE 8 and earlier, these definitions lived in /etc/apt/sources.list.d/pve-enterprise.list and ceph.list. On version 9 they do not. That single change is what breaks every guide written before August 2025, including our own guide for Proxmox VE 8.4, which remains correct for 8.x and wrong for 9.x.
The deb822 format, field by field
The old one-line format packed a repository into a single string: type, URL, suite, component. The deb822 format spreads the same information over named fields, one per line. Here is the enterprise definition as shipped:
Types: deb URIs: https://enterprise.proxmox.com/debian/pve Suites: trixie Components: pve-enterprise Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
Each field maps to something you already know:
- Types —
debfor binary packages,deb-srcfor sources. - URIs — the repository base URL. This is the field that carries the 401.
- Suites — the Debian release.
trixieis Debian 13, the base of Proxmox VE 9. On version 8 this readbookworm. - Components — which section of the repository to use.
- Signed-By — the GPG keyring used to verify package signatures.
Both formats are read by APT and can coexist on the same system. The practical difference is that the web interface writes .sources, so a system configured entirely in deb822 shows one consistent set of files whether you edit it from the shell or the browser.
Step 1 — Inspect what is actually configured
Do not delete anything before you have looked. The file names differ between versions, and on an upgraded node you may find leftovers from Proxmox VE 8.
ls -l /etc/apt/sources.list.d/
On a clean 9.2 install you should see three files:
total 12 -rw-r--r-- 1 root root 186 Aug 10 09:12 ceph.sources -rw-r--r-- 1 root root 187 Aug 10 09:12 debian.sources -rw-r--r-- 1 root root 174 Aug 10 09:12 pve-enterprise.sources
debian.sources holds the standard Debian repositories. They are public and working, and you leave them alone. The other two are the ones returning 401.
Read the Ceph one before touching it, because its URL tells you which Ceph release this node was built against:
cat /etc/apt/sources.list.d/ceph.sources
Types: deb URIs: https://enterprise.proxmox.com/debian/ceph-tentacle Suites: trixie Components: enterprise Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
Write down the codename in that URL. On Proxmox VE 9.2 it is normally ceph-tentacle. On a node installed with 9.0 or 9.1 it will read ceph-squid, and on a node upgraded from version 8 you may find ceph-reef or ceph-quincy in an old .list file. You will need that value in step 3.
Step 2 — Remove or disable the enterprise repositories
Removing the files is the shortest path:
rm -f /etc/apt/sources.list.d/pve-enterprise.sources rm -f /etc/apt/sources.list.d/ceph.sources
If you expect to buy a subscription later, comment the definitions instead of deleting them. In deb822 a leading # on every line disables the block and keeps it readable. There is also an Enabled: false field, which is cleaner and is what the web interface writes:
Types: deb URIs: https://enterprise.proxmox.com/debian/pve Suites: trixie Components: pve-enterprise Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg Enabled: false
On a node upgraded from Proxmox VE 8, check for stale .list files as well. They are still honoured by APT, and a forgotten one pointing at a Bookworm suite will produce confusing errors during the next upgrade:
ls -l /etc/apt/sources.list.d/*.list 2>/dev/null; grep -r bookworm /etc/apt/sources.list.d/ /etc/apt/sources.list
Step 3 — Add the no-subscription repositories
The Proxmox VE repository is required on every node. The Ceph repository is only required if the node participates in a Ceph cluster or needs the Ceph client libraries. Adding a Ceph repository you do not use is harmless but pointless, and it is one more thing to maintain when the Ceph release changes.
The deb822 form
This is the form to prefer, because it matches what the installer and the web interface produce. Create the Proxmox VE repository:
cat > /etc/apt/sources.list.d/pve-no-subscription.sources <<'EOF' Types: deb URIs: http://download.proxmox.com/debian/pve Suites: trixie Components: pve-no-subscription Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg EOF
Then, only on nodes that run Ceph, recreate the Ceph repository with the codename you noted in step 1:
cat > /etc/apt/sources.list.d/ceph.sources <<'EOF' Types: deb URIs: http://download.proxmox.com/debian/ceph-tentacle Suites: trixie Components: no-subscription Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg EOF
Note the component name. It is pve-no-subscription for Proxmox VE and plain no-subscription for Ceph. Getting these two confused produces a repository that resolves but has no package index, and APT will tell you the release file is missing rather than that the component is wrong.
The one-line form
The classic format still works and is quicker to type. It is the right choice if you are pasting a single command over a console:
echo "deb http://download.proxmox.com/debian/pve trixie pve-no-subscription" > /etc/apt/sources.list.d/pve-no-subscription.list
echo "deb http://download.proxmox.com/debian/ceph-tentacle trixie no-subscription" > /etc/apt/sources.list.d/ceph-no-subscription.list
One caveat if you mix formats: the same repository defined twice, once in each format, produces a duplicate-entry warning on every apt update. Pick one form per repository.
Step 4 — Pick the right Ceph release
Proxmox VE 9.2 ships Ceph Tentacle 20.2.1 as the default, with Ceph Squid 19.2.3 still available. The repository codename must match the Ceph packages installed on the node. Pointing a Squid cluster at the Tentacle repository is not a configuration choice, it is the first half of a major version upgrade, and it will offer to upgrade packages under a running cluster.
Check what is actually installed before you decide:
ceph --version
| Installed Ceph release | Repository path |
|---|---|
| Tentacle (20.x) | ceph-tentacle |
| Squid (19.x) | ceph-squid |
| Reef (18.x) | ceph-reef |
If ceph --version returns nothing, the node has no Ceph packages and you can skip the Ceph repository entirely. Upgrading between Ceph major releases is a separate procedure with its own ordering constraints, and it should never be triggered as a side effect of fixing a repository file. We cover cluster storage design and Ceph operations under unified storage infrastructure.
Step 5 — Update, then verify
apt update
The 401 errors should be gone, replaced by fetches from download.proxmox.com:
Hit:1 http://security.debian.org/debian-security trixie-security InRelease Hit:2 http://deb.debian.org/debian trixie InRelease Get:4 http://download.proxmox.com/debian/pve trixie InRelease [3,542 B] Get:5 http://download.proxmox.com/debian/ceph-tentacle trixie InRelease [3,571 B] Get:6 http://download.proxmox.com/debian/pve trixie/pve-no-subscription amd64 Packages [155 kB] Reading package lists... Done 52 packages can be upgraded. Run 'apt list --upgradable' to see them.
Read the list before applying it, particularly on a node carrying workloads:
apt list --upgradable
Then apply:
apt full-upgrade
Use full-upgrade rather than upgrade. Plain upgrade holds back any package that needs a new dependency, and on Proxmox that regularly means the kernel metapackage, so the node quietly stays behind. We leave out -y deliberately: on a production node, reading the summary before confirming is worth the extra keystroke.
Confirm the result:
pveversion
If the upgrade installed a new kernel, uname -r will still report the old one until you reboot. Both kernels remain installed, so the previous version is selectable from the GRUB menu if the new one misbehaves. On a cluster, reboot one node at a time, confirm with pvecm status that it has rejoined and the cluster holds quorum, and only then move to the next.
The same thing from the web interface
Everything above has a graphical equivalent. Select the node, then Updates > Repositories. The panel lists every configured repository with its status, and the Add button offers the standard definitions, including the no-subscription ones, without typing a URL. Disabling a repository from this panel writes Enabled: false into the .sources file rather than deleting it.
The panel is the better option for a single node, and it fails safe: it will not let you construct a URL that does not exist. The shell is the better option for a cluster, because the same command runs identically on every node and can be scripted.
No-subscription or enterprise: how to decide
The two repositories carry the same software. The difference is timing and support: packages reach the no-subscription repository first and the enterprise repository after a longer validation period, and only a subscription entitles you to Proxmox support.
For a lab, a development cluster, or a non-critical workload, the no-subscription repository is a reasonable default. For a production hypervisor carrying workloads you are accountable for, the argument for a subscription is less about the packages than about having a support channel when a node stops booting after an upgrade. Current pricing is published on the Proxmox website; we do not resell third-party licences, and this is a decision you take directly with the vendor.
What we do help with is the layer above that choice: sizing, network design, storage layout, and the operating procedures that make an upgrade a routine event rather than an incident. That work is described under private cloud and virtualisation.
One date to keep in mind
Proxmox VE 8 reaches end of life on 31 August 2026. After that date, the 8.x series receives no further security updates. If you are reading this while configuring repositories on an 8.4 node, the repository fix is the smaller half of the job: plan the upgrade to 9.x, and treat the repository configuration as the first step of that plan rather than as a standalone task.
What this guide does not cover
Three things were deliberately left out.
The upgrade from Proxmox VE 8 to 9 itself, which has its own prerequisites, its own ordering for clustered nodes, and a checklist tool worth running beforehand. It deserves its own article.
The Ceph major version upgrade, for the same reason: changing the repository codename is one line, and doing it safely under a running cluster is not.
The subscription notice that appears at login on a no-subscription node. Removing it means patching a file owned by a package, which means the patch is reverted on the next update of that package, silently. It is widely documented elsewhere and we do not recommend it on any system you intend to keep updated.
If you are running through this on a cluster rather than a single node, the order matters more than the commands do. That is usually where the time goes.
