Search results

it does seem to work on PVE 9.1.. (it doesn't add the `contact`, but the account is selectable/usable ;))

das klingt so als haettest du das archive keyring paket an den falschen ort runter geladen, before du PVE (on top of Debian?) installiert hast.. die beiden angegebenen files kannst du auf jeden fall loeschen, die haben in dem ordner nix zu suchen ;)

like I said - if you are worried about this scenario, you can give PDM read-only access and use it as a dashboard. if you want it to (actively) manage PVE systems, you need to give it the privileges to do so, and secure it/restrict access to it accordingly.

how did that second command error out? the error is not contained in the strace because of the string censoring ;) could you run strace on the first command as well? thanks! I suspect the erroring out was caused by: 1175:ioctl(8, BLKZEROOUT, [2147479552, 3584]) = -1 EINVAL (Invalid argument)...

if your PDM is compromised, and you login using your PVE admin credentials (under your proposed scheme), the same is true. if you are worried about this risk, don't use your PDM for administration at all, just use it as a dashboard.

to shed some further light into the internals of PBS: blobs are never referencing chunks. blobs and chunks are the same thing format-wise, just used for different purposes: - chunk: blob stored in the chunk store, to be referenced by indices via its digest - blob: blob stored in a metadata dir...

please post a backup task log. client-side deduplication can only happen if there is a previous snapshot on the backup target (datastore+namespace+group!) that is not a in a verification-failed state. based on your description I suspect you have created new backup groups in a new empty...

that would just be more complicated, but still require PDM to have all that access to PVE.. it would also make certain optimizations impossible, like collecting metrics/tasks/status/.. once and exposing it to different PDM users (with filtering).

backport patch was sent by @tchaikov : https://lore.proxmox.com/pve-devel/20251216125648.546017-2-k.chai@proxmox.com/T/#u

sorry to hear that. if the VM is still around, you could run another backup, that might re-upload some of the missing chunks and thus "heal" some of the backups.

this would require a reproducer first. but yes, it is possible the issue is triggered by a certain network workload/traffic pattern/.., which might very well be specific to our code (or otherwise very rare). we can't make code more robust if we don't know what the actual cause of the problem is.

that's a totally different issue - the container extraction/initialization happens as unprivileged user, and your NFS server doesn't allow unprivileged access.

that might be possible, yes. or a connection issue, but if it is reproducibly always the same sector than I'd say it's likely that the corresponding chunk has an issue. did you try verifying the snapshot already?

you need to look on the node that your PVE UI talks to/is connected to

you need to look on the right node, in case this is a cluster.

on the UI there should be a little folder icon in the actions column for the pxar.didx entry, if you click that a file browser should open.

proxmox-boot-tool basically does what you want - it moves the bootloader, kernel and initrd files to the ESP, which means the bootloader doesn't need to access / anymore during boot.

a pxar backup (unless it is encrypted) should be browseable from the PBS UI directly.. if it isn't, then likely that client is doing something wrong..

thanks! if you retry (please ensure there are no other file restore tasks running in parallel), could you post the /var/log/proxmox-backup/file-restore/qemu.log file corresponding to your file restore?

okay, so it's not a 32G file size limit ;) is this a VM or a container backup? are you using the PVE or the PBS UI to download?