I will tell you a little secret, you taught me more than that one command for CLI lol
One more important note for my Bitwarden
Thanks again bud!

OMG I guess that's what happens when you try to to work on two labs same time, I mixed the lab1 subnet I'm working on with the lab2 on my last mount attempt.
I changed it to the correct subnet and it mounted properly this time

Can it be that unmounting it in cli fixed the issue?
I am going to try the same unmount command on lab1 setup, and see if that will get it going also.

Thank you so much @Pilow . I appreciate the time and energy you spend helping me with this one!

xo@xo-ce:~$ mount -t nfs
xo@xo-ce:~$ sudo mount -v -t nfs -o vers=3 192.168.221.20:/LAB-NFS /run/xo-server/mounts/LAB-NFS/
mount.nfs: timeout set for Thu Nov 20 16:50:18 2025
mount.nfs: trying text-based options 'vers=3,addr=192.168.221.20'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.221.20 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 192.168.221.20 prog 100005 vers 3 prot UDP port 54698
xo@xo-ce:~$ mount -t nfs
192.168.221.20:/LAB-NFS on /run/xo-server/mounts/LAB-NFS type nfs (rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.221.20,mountvers=3,mountport=54698,mountproto=udp,local_lock=none,addr=192.168.221.20)
xo@xo-ce:~$ sudo umount /run/xo-server/mounts/LAB-NFS
xo@xo-ce:~$ mount -t nfs

So mounting in CLI seems to show it created a mount but i do not see it in the gui. so I unmounted it again and tried to remount in the gui remotes, its did add the remote but after a while, it gave a timeout error

{
"shortMessage": "Command failed with exit code 32: mount -o hard -t nfs 192.168.45.20:/LAB-NFS /run/xo-server/mounts/eecbb7da-e271-4c39-9681-5b50f8d65e9a",
"command": "mount -o hard -t nfs 192.168.45.20:/LAB-NFS /run/xo-server/mounts/eecbb7da-e271-4c39-9681-5b50f8d65e9a",
"escapedCommand": "mount -o hard -t nfs "192.168.45.20:/LAB-NFS" "/run/xo-server/mounts/eecbb7da-e271-4c39-9681-5b50f8d65e9a"",
"exitCode": 32,
"stdout": "",
"stderr": "mount.nfs: Connection timed out",
"failed": true,
"timedOut": false,
"isCanceled": false,
"killed": false
}

xo@xo-ce:/run/xo-server/mounts/LAB-NFS$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether c6:e3:43:a1:5b:e7 brd ff:ff:ff:ff:ff:ff
inet 192.168.221.24/24 brd 192.168.221.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::c4e3:43ff:fea1:5be7/64 scope link
valid_lft forever preferred_lft forever

What gets me is that if it was permissions related, theoretically, it should not mount the nfs storage SR with the same settings pointing to the xcpng host from the same qnap?!
It feels like something is different between the xoa nfs implementation and the xcpng host itself.
Dont you agree?

.22 XCP-ng host
.24 XOA
.115 Unraid server1 - Able to mount with no issues
.114 Unraid server2 - Able to mount with no issues

@Pilow That seems did the trick!
xo@xo-ce:/run/xo-server/mounts/LAB-NFS$ sudo mount -v -t nfs -o vers=3 192.168.221.20:/LAB-NFS /run/xo-server/mounts/LAB-NFS/
mount.nfs: timeout set for Thu Nov 20 15:42:55 2025
mount.nfs: trying text-based options 'vers=3,addr=192.168.221.20'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.221.20 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 192.168.221.20 prog 100005 vers 3 prot UDP port 54698
mount.nfs: mount(2): Device or resource busy
xo@xo-ce:/run/xo-server/mounts/LAB-NFS$ ping 192.168.221.20
PING 192.168.221.20 (192.168.221.20) 56(84) bytes of data.
64 bytes from 192.168.221.20: icmp_seq=1 ttl=64 time=0.884 ms
64 bytes from 192.168.221.20: icmp_seq=2 ttl=64 time=0.531 ms
64 bytes from 192.168.221.20: icmp_seq=3 ttl=64 time=0.507 ms
64 bytes from 192.168.221.20: icmp_seq=4 ttl=64 time=0.648 ms
64 bytes from 192.168.221.20: icmp_seq=5 ttl=64 time=0.496 ms
^C
--- 192.168.221.20 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4082ms
rtt min/avg/max/mdev = 0.496/0.613/0.884/0.145 ms
xo@xo-ce:/run/xo-server/mounts/LAB-NFS$

Why would it time out if it does mount nfs sr from the same qnap and same permission settings?! My head is starting to smoke lol

@Pilow seems the same error
xo@xo-ce:/run/xo-server/mounts/LAB-NFS$ sudo mount -t -v nfs -o vers=3 192.168.221.20:/LAB-NFS /run/xo-server/mounts/LAB-NFS/
mount: bad usage
Try 'mount --help' for more information.

@Pilow Sorry for the delay, bud, I was on the road all day yesterday.
I have to admit, when it comes to CLI I struggle.
I tried to figure out the mounting command as follows:
xo@xo-ce:/run/xo-server/mounts/LAB-NFS$ sudo mount -t nfs -o vers=3 192.168.221.20:/LAB-NFS /run/xo-server/mounts/LAB-NFS/
xo@xo-ce:/run/xo-server/mounts/LAB-NFS$ sudo mount -t -vvv nfs -o vers=3 192.168.221.20:/LAB-NFS /run/xo-server/mounts/LAB-NFS/
mount: bad usage
Try 'mount --help' for more information.

The mount command alone seemed to kick no error, but I do not see any remote/storage created in the gui.
When I try to add -vvv, it complains

-= Update =-
Tried to expose the Unraid server container to the host network, everything seemed perfect and pings work both ways, while nfs still giving me the same error only for mounting remotes (both from QNAP and the same host Unraid server.

I decided to install another fresh XCP-ng host server just to eliminate my first host configuration, but I got the same result, remotes would not mount.

The last idea was to remove the XOA container VM running on the Unraid server and download the prebuilt XOA VM image directly from the XCP-ng host. This gave me a timeout error when trying to mount off QNAP with permissions set to both the new XOA IP and the XCP-ng host IP.
remote.test
{
"id": "7903a500-ee84-43dc-bd3e-b6c7abe8381b"
}
{
"shortMessage": "Command failed with exit code 32: mount -o hard -t nfs 192.168.45.20:/LAB-NFS /run/xo-server/mounts/7903a500-ee84-43dc-bd3e-b6c7abe8381b",
"command": "mount -o hard -t nfs 192.168.45.20:/LAB-NFS /run/xo-server/mounts/7903a500-ee84-43dc-bd3e-b6c7abe8381b",
"escapedCommand": "mount -o hard -t nfs "192.168.45.20:/LAB-NFS" "/run/xo-server/mounts/7903a500-ee84-43dc-bd3e-b6c7abe8381b"",
"exitCode": 32,
"stdout": "",
"stderr": "mount.nfs: Connection timed out",
"failed": true,
"timedOut": false,
"isCanceled": false,
"killed": false,
"message": "Command failed with exit code 32: mount -o hard -t nfs 192.168.45.20:/LAB-NFS /run/xo-server/mounts/7903a500-ee84-43dc-bd3e-b6c7abe8381b
mount.nfs: Connection timed out",
"name": "Error",
"stack": "Error: Command failed with exit code 32: mount -o hard -t nfs 192.168.45.20:/LAB-NFS /run/xo-server/mounts/7903a500-ee84-43dc-bd3e-b6c7abe8381b
mount.nfs: Connection timed out
at makeError (/opt/xo/xo-builds/xen-orchestra-202511150402/node_modules/execa/lib/error.js:60:11)
at handlePromise (/opt/xo/xo-builds/xen-orchestra-202511150402/node_modules/execa/index.js:118:26)
at NfsHandler._sync (/opt/xo/xo-builds/xen-orchestra-202511150402/@xen-orchestra/fs/src/_mount.js:68:7)"
}

BUT
If I configured a completely unsecured public NFS share on the Unraid server, I then managed to get it mounted successfully. (using the XOA vm running on the XCP-ng host.

When I changed the share to Private with granting permissions to the IP of the host and the XOA VM IPs, I get permissions denied yet again.

At this point, I'm at a loss, there must be a way to grant access to an IP and make it work with remote. Clearly, I know how to grant permissions as the NFS SR and the Unraid mount of the secured NFS from QNAP are working with no issues.

Must be something stupid I'm missing.

@Pilow said in Unable to mount NFS Remote for backups while storage and ISO NFS SR's work perfectly:

It was. Both the host ip and the xoa.
Thanks for the super fast replies guys!
I got an idea, I'm going to try and investigate, the XOA is running in a container. I'm going to test if the passthrough of the container manager network may be blocking the NFS.

Hello Friends,

I am testing a fresh install of xcpng 8.3 with community XO

while I am able to mount both ISO NFS SR and VDI NFS SR from both Synology and Qnap NAS boxes, on the same subnet, I am unable to mount any NFS remotes for backups from the same two NAS boxes.
The error log is:
remote.test
{
"id": "d43307ac-afc3-42cb-89af-3892f1fe592c"
}
{
"shortMessage": "Command failed with exit code 32: mount -o -t nfs 192.168.221.20:/LAB-NFS /run/xo-server/mounts/d43307ac-afc3-42cb-89af-3892f1fe592c",
"command": "mount -o -t nfs 192.168.221.20:/LAB-NFS /run/xo-server/mounts/d43307ac-afc3-42cb-89af-3892f1fe592c",
"escapedCommand": "mount -o "" -t nfs "192.168.221.20:/LAB-NFS" "/run/xo-server/mounts/d43307ac-afc3-42cb-89af-3892f1fe592c"",
"exitCode": 32,
"stdout": "",
"stderr": "mount.nfs: failed to prepare mount: Operation not permitted
",
"failed": true,
"timedOut": false,
"isCanceled": false,
"killed": false,
"message": "Command failed with exit code 32: mount -o -t nfs 192.168.221.20:/LAB-NFS /run/xo-server/mounts/d43307ac-afc3-42cb-89af-3892f1fe592c
mount.nfs: failed to prepare mount: Operation not permitted
",
"name": "Error",
"stack": "Error: Command failed with exit code 32: mount -o -t nfs 192.168.221.20:/LAB-NFS /run/xo-server/mounts/d43307ac-afc3-42cb-89af-3892f1fe592c
mount.nfs: failed to prepare mount: Operation not permitted

at makeError (/etc/xen-orchestra/node_modules/execa/lib/error.js:60:11)
at handlePromise (/etc/xen-orchestra/node_modules/execa/index.js:118:26)
at NfsHandler._sync (/etc/xen-orchestra/@xen-orchestra/fs/src/_mount.js:68:7)"

}

Thinking of permissions issue, I went ahead and tried to mount the same qnap nfs folder with the same permissions settings I am using for the XO remote onto an UnRaid server, which worked on the first try, leading me to believe I'm missing something on xcp or XO end.

Any ideas to point me to the correct direction would be appreciated.
FYI I used web gui for everything.

@Danp Got you, thanks for the clarification!

@StormMaster said in Restoring from backup error: self-signed certificate:

BRANCH="0ccfd4b"
This worked for me also, thank you.

But after this change, I have tried to run update few times but it seems my commits are falling behind and do not update to the latest.
Am I missing something?

@SchaffnerOnline I just confirmed my "fast clone" was checked!

I ran another test with "fast clone" unchecked just now.

After clicking Create it took a few minutes but then it seemed like my XO disconnected from the master as I got the "Welcome to Xen Orchestra!" page to connect a server.
A few minutes later it came back with a new VM which I created from the template.

Checked my templates, and there is no new template there.

I tried twice, one with local storage and one with NFS SR both with the same outcome. both vms were booting up with no problem.

@DustinB I have tried to reproduce it, no luck, it worked like a charm.
I took a working VM, shut it down, converted it to the template, went to add VM, chose the template, renamed, clicked create, and a few sec after I got a functional VM.
On this commit:

Then I fired up the commit with the broken self-signed cert but it worked there also.

@Danp Thanks for the tip bud!
I will search that topic and experiment some more.

Hello everyone,

I am testing (beating) a fresh install of community XO and XC-png.
After the last restore bug which left me with many stuck tasks, I decided to keep at it and give it more testing.

On top of trying GUI "cancel task" I also tried ssh "xe task-cancel force=true uuid=taskuuid"
and both failed.

Pulling power on hosts did the trick lol

Then when everything was back online I pulled the network plug on the NFS DR for a while and plugged it back which made the XO VM running on it also freeze as well as Async.SR.scan frozen task for that SR.
I have tried to "force shutdown" that XO VM which led to another frozen task (Async.VM.hard_shutdown)
and lastly i have tried "xe vm-reset-powerstate --force --multiple"
which worked after also being frozen for about 4-6 minutes.

I am very new to xc-png and xo projects so my question is, did I miss anything? So far the only solutions I found to work are not solutions that are very "safe" and I wouldn't use them on production vms and/hosts.
Did anyone experience "frozen" unrebootable vms when they had NFS SR outage?
What troubleshooting steps do you recommend for me to try when this situation is recreated?

Thanks a lot!

Same issue here with the latest XO

I tested restore from Qnap with NFS, and there were no errors it's just stuck in tasks with no movement and no way to cancel.

If it helps everything is with default self-signed certificates.
Backups run with no issues, just something with the restore.