Search results

see some discussion here: https://bugzilla.proxmox.com/show_bug.cgi?id=5552

could you post the output of pve8to9 as well as "proxmox-boot-tool status" and "efibootmgr -v" for the third node, *before doing the upgrade*? thanks!

the fix is still not included, I'll ping it once more.

yes, I got a GH notification about it but it was too close to the cutoff for the next point release (this weekend) on the Debian side. I will get it included in unstable and then try to get it backported for Debian 13.4 (which will be cut in March).

is this running inside a container? which kind? if it's a PVE LXC container, could you post the config? the issue that it's not possible to mount the tmpfs: Dec 26 14:50:29 pbs-vaduz systemd[1]: Mounting run-proxmox\x2dbackup.mount - Mount tmpfs at /run/proxmox-backup...<br>Dec 26 14:50:29...

drwxrwx--- root root nfsshare this means it's not accessible for unprivileged users..

this absolutely should not be necessary.. please post the output of "journalctl -b" and "proxmox-backup-manager versions --verbose"

please post your exact ACLs..

https://bugzilla.proxmox.com/show_bug.cgi?id=7159

could you try the 6.14 kernel as well? if that also doesn't work, it really looks like a network/load issue on your system(s).. regarding the task log on the UI - could you try accessing them using the CLI and/or using a fresh, new browser profile? are there any errors in the browser dev console?

verify hat primaer die funktion bit-rot zu erkennen und auf vollstaendigkeit zu pruefen, macht also durchaus sinn dass auch am sync target periodisch zu machen.

you give your students access to all VMs, they have access to all VMs. remove the ACL giving access to /vms with propagation, then the user will only be able to create guests in the pool, and attempts to create one without a pool set will fail. you also don't need to set NoAccess on all those...

you need to give them access to the bridge/vnet (those have their own ACL paths and privilege). Sys.AccessNetwork is entirely unrelated, as are most other privileges you listed. see https://pve.proxmox.com/pve-docs/pve-admin-guide.html#_privileges

verify direkt nach dem snapshot erzeugen erzeugt last, wenn moeglicherweise noch andere backups ausstehen die davon beeintraechtigt werden koennten. ausserdem ist verify umso effizienter, je groesser der scope ist (weil chunks die von mehreren snapshots referenziert werden, nur einmal geprueft...

could you try updating both ends to the 6.17.4-2 kernel on pbs-test? there is a known issue with older 6.17 kernels that can lead to TCP connection stalls.. if that doesn't help, you could try the 6.14 kernel next. although the symptoms don't match exactly, so there might be a different issue...

you can give the PVE access token only access to read old backups and create new ones, but not remove/prune backups. you can combine this with a sync job on the PBS side to keep an offsite archive that is decoupled from the main PBS system (with separate pruning, verification and GC).

well, the scheduled backup job runs on all nodes in your cluster, so likely you have more load on the NAS side in that case, increasing the chances of triggering the issue..

could you still file an issue in our bugzilla with the details (and maybe some references to those upstream reports)?

filed https://bugzilla.proxmox.com/show_bug.cgi?id=7183 for improving the handling!

mp0: vault:subvol-305-disk-1,mp=data,backup=1,size=20000G the "data" there should be "/data". it seems this is not handled correctly in the backup code, but works by chance during regular startup.