Search results

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.

I mean "pct config XXX", where XXX is the container's ID

please post the config(s) nevertheless..

could you post the config of the affected container?

it does sound like the error is coming from the storage, maybe it doesn't like renaming the file while it's still being flushed? hard to say from the distance.. if you have the space, you might try switching the backup target to a local disk and see if the problem disappears then..

I don't think this is exposed yet via the CLI, feel free to file an enhancement request in our bugzilla!

could you file an issue in our bugzilla? please include "pveversion -v", the config and the task log! this should be possible to fix.. recreating the TPM state is an option, but it will possibly require recovering bitlocker inside the VM using recovery codes, so it is a bit dangerous.

well it is already - if you want to test the fix, upgrade to the fixed version (the diff between -4 and -5 is only that fix).

klingt nach nem plan. etwaige fehler im journal waeren auch interessant!

there are multiple issues, the io_uring is only fixed in 10.1.2-5 which is currently on pve-test