Rollback fails with "TASK ERROR: zfs error: cannot set property for <subvol>: use 'none' to disable quota/refquota"

[lubbdi]

Hey all,

I bumped into this error message while rolling back a LXC container snapshot from around a month ago:

TASK ERROR: zfs error: cannot set property for 'data/enc/subvol-108-disk-0': use 'none' to disable quota/refquota

The CT Rollback task enters "failed" state and keeps the container in locked mode.

The quota,refquota of this pool (and the dataset) are:

root@pve:~# zfs get quota,refquota data/enc
NAME      PROPERTY  VALUE     SOURCE
data/enc  quota     none      default
data/enc  refquota  none      default

The snapshot was created with an earlier version of Proxmox at that time, currently it's running version 9.2.3:

root@pve:~# pveversion -v
proxmox-ve: 9.2.0 (running kernel: 7.0.6-2-pve)
pve-manager: 9.2.3 (running version: 9.2.3/d0fde103346cf89a)
proxmox-kernel-helper: 9.2.0
proxmox-kernel-7.0: 7.0.6-2
proxmox-kernel-7.0.6-2-pve-signed: 7.0.6-2
proxmox-kernel-7.0.0-3-pve-signed: 7.0.0-3
proxmox-kernel-6.14: 6.14.11-9
proxmox-kernel-6.14.11-9-pve-signed: 6.14.11-9
proxmox-kernel-6.14.11-7-pve-signed: 6.14.11-7
proxmox-kernel-6.14.11-3-pve-signed: 6.14.11-3
proxmox-kernel-6.14.8-2-pve-signed: 6.14.8-2
proxmox-kernel-6.8.12-13-pve-signed: 6.8.12-13
proxmox-kernel-6.8: 6.8.12-13
proxmox-kernel-6.8.12-4-pve-signed: 6.8.12-4
amd64-microcode: 3.20251202.1~bpo13+1
ceph-fuse: 19.2.3-pve1
corosync: 3.1.10-pve2
criu: 4.1.1-1
ifupdown2: 3.3.0-1+pmx12
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-5
libproxmox-acme-perl: 1.7.1
libproxmox-backup-qemu0: 2.0.2
libproxmox-rs-perl: 0.4.1
libpve-access-control: 9.1.1
libpve-apiclient-perl: 3.4.2
libpve-cluster-api-perl: 9.1.6
libpve-cluster-perl: 9.1.6
libpve-common-perl: 9.1.13
libpve-guest-common-perl: 6.0.3
libpve-http-server-perl: 6.0.5
libpve-network-perl: 1.6.6
libpve-notify-perl: 9.1.6
libpve-rs-perl: 0.15.3
libpve-storage-perl: 9.1.5
libspice-server1: 0.15.2-1+b1
lvm2: 2.03.31-2+pmx1
lxc-pve: 7.0.0-2
lxcfs: 7.0.0-pve1
novnc-pve: 1.7.0-1
openvswitch-switch: 3.5.0-1+b1
proxmox-backup-client: 4.2.1-1
proxmox-backup-file-restore: 4.2.1-1
proxmox-backup-restore-image: 1.0.0
proxmox-firewall: 1.2.3
proxmox-kernel-helper: 9.2.0
proxmox-mail-forward: 1.0.3
proxmox-mini-journalreader: 1.6
proxmox-offline-mirror-helper: 0.7.4
proxmox-widget-toolkit: 5.2.3
pve-cluster: 9.1.6
pve-container: 6.1.10
pve-docs: 9.2.2
pve-edk2-firmware: 4.2025.05-2
pve-esxi-import-tools: 1.0.1
pve-firewall: 6.0.4
pve-firmware: 3.18-4
pve-ha-manager: 5.2.4
pve-i18n: 3.7.5
pve-qemu-kvm: 11.0.0-4
pve-xtermjs: 6.0.0-1
qemu-server: 9.1.16
smartmontools: 7.5-pve2
spiceterm: 3.4.2
swtpm: 0.8.0+pve3
vncterm: 1.9.2
zfsutils-linux: 2.4.2-pve1

The ZFS pool uses encryption, in case that makes a difference.
I couldn't find any related topic in the forum, and appreaciate any help. Thanks!

 

[j.theisen]

Hi @lubbdi

thanks for posting in the forum!

There was in issue a few years back which behaved similar, but as can be seen in [1] that was fixed a long time ago.

Can you please share the configuration of the container you are trying to restore with "Show configuration" on the Backup page.

Is this common behavior on your host or is just this one container affected?

Yours sincerely
Jonas

[1] https://bugzilla.proxmox.com/show_bug.cgi?id=3345

 

[j.theisen]

EDIT: Sorry, i misread your post and thought this was concerning a Backup restore.
So please ignore my request for the configuration and instead please provide the container config by running cat /etc/pve/lxc/<CT-ID>.conf

 

[lubbdi]

Here's the config file at the time of my post:

root@pve:~# cat /etc/pve/lxc/108.conf
[pre_2026]
arch: amd64
cores: 6
features: nesting=1
hostname: horst
memory: 2048
nameserver: 9.9.9.11
net0: name=eth0,bridge=vmbr0,firewall=1,gw=xxx.yyy.aaa.bb,gw6=2a01:db8::2,hwaddr=BC:24:11:5A:0E:A0,ip=ccc.dd.yyy.zzz/29,ip6=2a01:db8::108/64,type=veth
ostype: debian
rootfs: data_enc:subvol-108-disk-0,size=30G
snaptime: 1778269541
swap: 512
unprivileged: 1

arch: amd64
cores: 6
features: nesting=1
hostname: horst
memory: 2048
nameserver: 9.9.9.11
net0: name=eth0,bridge=vmbr0,firewall=1,gw=xxx.yyy.aaa.bb,gw6=2a01:db8::2,hwaddr=BC:24:11:5A:0E:A0,ip=ccc.dd.yyy.zzz/29,ip6=2a01:db8::108/64,type=veth
ostype: debian
parent: pre_2026
rootfs: data_enc:subvol-108-disk-0,size=2G
swap: 512
unprivileged: 1

Note that I don't have this snapshot anymore, I recovered it by manually doing a zfs rollback data/enc/subvol-108-disk-0@pre_2026, which luckily worked, and removed its entry from this config file afterwards.

Before the zfs rollback, I also tried pct rollback 108 pre_2026, which yielded the same error message as seen in the web interface.

What got me thinking was the 30G vs. 2G disk size, before and after the rollback it was 2G, but I definitely created the container with 30G.