@poddingue https://github.com/vatesfr/xen-orchestra/issues/9779

carloum70-lab created this issue in vatesfr/xen-orchestra

open File level restore error: Error while scanning disk #9779

Is there some update? Can this issue be reproduced?

@ataxyanetwork I managed to install XOA (Current version: 6.2.2 - XOA build: 20251219) and did some more testing.

I am experiencing the same issue when trying to restore from an existing backup.

When I create a new backup job, I can perform a filelevel restore without any problems. However, when I rerun the job, I am no longer able to restore from the most recent backup. It only works with the initial backup.

Can you also reproduce this ?

@AtaxyaNetwork This is not going to work because our nodes don't have access to the internet.
If it works using XOA, what conclusion can we draw? Migrate to XOA ?

@AtaxyaNetwork Thank you for the quick response.
"Are you running an XO source with LVM for the OS ?" --> no

You did the restore using XOA instead of XO from source ?
To Install XOA I have to install a new instance and import the config of my current XO ?
I will test this tomorrow.

@AtaxyaNetwork Sorry forgot to add this to my topic.

XOA - commit 3ed8c
VM's are based on Debain13
UEFI
Backup mode: Delta backup

~# lsblk -f 
NAME              FSTYPE      FSVER    LABEL UUID                                   FSAVAIL FSUSE% MOUNTPOINTS
xvda                                                                                               
├─xvda1           vfat        FAT32          0E7D-17B9                               965.3M     1% /boot/efi
├─xvda2           ext4        1.0            bf2a2e01-b9ff-4b93-a824-ba7562461c15      1.3G    20% /boot
├─xvda3           LVM2_member LVM2 001       v2o7yJ-51Hc-sO1m-ubrj-YCvP-7Zo2-zOjxzZ                
│ ├─vgdata-lvroot ext4        1.0            d0e71b5a-5404-4b18-9249-eb222a6d346d     22.6G     6% /
│ ├─vgdata-lvhome ext4        1.0            5aa25f3d-708d-4708-8405-a97391e2e989      4.3G     0% /home
│ └─vgdata-lvvar  ext4        1.0            e82f5584-810b-40e2-a6e6-ed05805146db      3.5G    30% /var
└─xvda4           swap        1              6124f717-58cf-47a8-b268-4c99dcd495d0                  [SWAP]

Hi all,

First of all, I am aware that there are still issues with file-level restores and LVM. However, for some unknown reason, I am now encountering a new error when selecting the disk during the restore procedure.- Error while scanning disk

Apr 16 11:08:34 dacsvm-xoa xo-server[3124716]: 2026-04-16T09:08:34.366Z xo:api WARN admin | backupNg.listPartitions(...) [214ms] =!> Error: Command failed: vgchange -an vgdata
Apr 16 11:08:34 dacsvm-xoa xo-server[3124716]: File descriptor 23 (/var/lib/xo-server/data/leveldb/LOG) leaked on vgchange invocation. Parent PID 3124716: node
Apr 16 11:08:34 dacsvm-xoa xo-server[3124716]: File descriptor 24 (/var/lib/xo-server/data/leveldb/LOCK) leaked on vgchange invocation. Parent PID 3124716: node
Apr 16 11:08:34 dacsvm-xoa xo-server[3124716]: File descriptor 25 (/var/lib/xo-server/data/leveldb/000379.log) leaked on vgchange invocation. Parent PID 3124716: node
Apr 16 11:08:34 dacsvm-xoa xo-server[3124716]: File descriptor 28 (/var/lib/xo-server/data/leveldb/MANIFEST-000377) leaked on vgchange invocation. Parent PID 3124716: node
Apr 16 11:08:34 dacsvm-xoa xo-server[3124716]: File descriptor 37 (/dev/fuse) leaked on vgchange invocation. Parent PID 3124716: node
Apr 16 11:08:34 dacsvm-xoa xo-server[3124716]:   WARNING: Not using device /dev/loop0 for PV v2o7yJ-51Hc-sO1m-ubrj-YCvP-7Zo2-zOjxzZ.
Apr 16 11:08:34 dacsvm-xoa xo-server[3124716]:   WARNING: PV v2o7yJ-51Hc-sO1m-ubrj-YCvP-7Zo2-zOjxzZ prefers device /dev/xvda3 because device is used by LV.
Apr 16 11:08:34 dacsvm-xoa xo-server[3124716]:   Logical volume vgdata/lvroot contains a filesystem in use.
Apr 16 11:08:34 dacsvm-xoa xo-server[3124716]:   Can't deactivate volume group "vgdata" with 3 open logical volume(s)

Is this also a known issue ?
Do you have an estimate for when LVM support will be available? This is currently a deal breaker for us, as our infrastructure (running on XCP-ng) is becoming increasingly business-critical.
If this is not supported in the near future, we may need to consider alternative backup solutions.

XOA - commit 3ed8c
VM's are based on Debain13
Backup mode: Delta backup

Regards,
Carlo

Thanks for the reply's! This really helps.

I added the

console.log('OIDC profile:', JSON.stringify(profile, null, 2))

and then tried with the following:

username field: email
scope: email

logging:

mrt 30 12:34:57 vm-xoa xo-server[2747568]: OIDC profile: {
mrt 30 12:34:57 vm-xoa xo-server[2747568]:   "id": "38882f04f015223135313da0b919cb3d67bf4fbc@sram.surf.nl"
mrt 30 12:34:57 vm-xoa xo-server[2747568]: }
mrt 30 12:34:57 vm-xoa xo-server[2747568]: Cannot read properties of undefined (reading '0')

username field: uid
scope: uid

logging:

mrt 30 12:35:54 vm-xoa xo-server[2747568]: OIDC profile: {
mrt 30 12:35:54 vm-xoa xo-server[2747568]:   "id": "38882f04f015223135313da0b919cb3d67bf4fbc@sram.surf.nl"
mrt 30 12:35:54 vm-xoa xo-server[2747568]: }
mrt 30 12:35:54 vm-xoa xo-server[2747568]: Expected values to be strictly equal:
mrt 30 12:35:54 vm-xoa xo-server[2747568]: + actual - expected
mrt 30 12:35:54 vm-xoa xo-server[2747568]: + 'undefined'
mrt 30 12:35:54 vm-xoa xo-server[2747568]: - 'string'

So it seems that in both cases we only receive the "sub" from the scope openid from surf. Which is here named "id". Is this translated by xo?

Then I applied the patch from @olivierlambert . Therafter we were able to login by using "id" as Username field, "sub" returned an error. The user 38882f04f015223135313da0b919cb3d67bf4fbc@sram.surf.nl was then created.

If I use email or uid we get now better logging:

mrt 30 12:41:14 vm-xoa xo-server[2747760]: Could not find username: field "uid" is missing from the OIDC profile. Ensure the required scopes are configured and granted by your identity provider.
mrt 30 12:42:27 vm-xoa xo-server[2747760]: Could not find username: field "email" is missing from the OIDC profile. Ensure the required scopes are configured and granted by your identity provider.

We will check if we have to enable/allow additional claims from the authentication provider to be available and let you now.

@HeMaN

We would like to know that too.

It seems that xo is receiving something, but not what it is expecting. But unfortunately we cannot see what it receives.

With a saml tracer plugin I can see data that my browser exchanges with Surf and there are the field that are used/needed, like the uid and the mail.

But from my understanding xo requests its own data from surf based on token from the web session.

We are running Xen Orchestra with commit c3dcb and the auth-oidc (v0.4.2) plugin.

The users that login are unique and not yet present as local users.

The OICD provider is SURF with SRAM: https://www.surf.nl/en/services/identity-access-management/surf-research-access-management

They support the following attributes/scopes: https://servicedesk.surf.nl/wiki/spaces/IAM/pages/74226142/Attributes+in+SRAM

There are some IPs that need to be accessable: https://servicedesk.surf.nl/wiki/spaces/IAM/pages/74226067/IP+addresses#IPaddresses-OIDC . Outgoing traffic from the server to port 443 is open and works.

We did try several settings for the Username field and scopes.

For example the following:

This should create a user R123456789

The logging shows the following:

mrt 27 09:29:48 vm-xoa xo-server[2641104]: Expected values to be strictly equal:
mrt 27 09:29:48 vm-xoa xo-server[2641104]: + actual - expected
mrt 27 09:29:48 vm-xoa xo-server[2641104]: + 'undefined'
mrt 27 09:29:48 vm-xoa xo-server[2641104]: - 'string'

If we change it to:

The following shows up:

mrt 27 09:32:21 vm-xoa xo-server[2641104]: Cannot read properties of undefined (reading '0')

I hope this helps to understand the problem. Thanks.