SR_BACKEND_FAILURE_108 | Unable to Add a Second NFS Storage Repository

kagbasi-ngc

Good-day Folks,

MY ENVIRONMENT:

XCP-ng: 3 nodes running v8.3
XOA: v5.99 (air-gapped build)
NFS Server: Windows Server 2016
Networking: Management network of hosts exist within the same VLAN as NFS Server

While attempting to add a second NFS SR to my 3-node pool, via XOA (air-gapped), yesterday I ran into the following error message:

Error code:  SR_BACKEND_FAILURE_108
Error parameters: , Unable to detect an NFS service on this target.,

What's strange about this error is that I already have an NFS SR defined which targets this exact server and is functioning okay (as I can created new VMs and put their VDIs there, as well as execute an SR rescan - which doesn't appear to fail). Additionally, as you can see from the below SSH output from one of the hosts, I can reach the NFS server without issues but unable to enumerate the exports:

[22:26 VMH01 ~]# ping testsvr01
PING testsvr01.LabNET.local (10.0.10.10) 56(84) bytes of data.
64 bytes from TESTSVR01.LabNET.local (10.0.10.10): icmp_seq=1 ttl=128 time=0.341 ms
64 bytes from TESTSVR01.LabNET.local (10.0.10.10): icmp_seq=2 ttl=128 time=0.387 ms
64 bytes from TESTSVR01.LabNET.local (10.0.10.10): icmp_seq=3 ttl=128 time=0.337 ms
^C
--- testsvr01.LabNET.local ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2032ms
rtt min/avg/max/mdev = 0.337/0.355/0.387/0.022 ms
[22:27 VMH01 ~]#
[22:27 VMH01 ~]# showmount -e testsvr01
clnt_create: RPC: Port mapper failure - Timed out
[22:29 VMH01 ~]#

While doing some Googling around, I've seen a suggestion in another forum to run rpcinfo -p against the server to see which ports are open, so I'll try that when I get to work. However, if anyone has seen this issue before on XOA or XOCE, please chime in with some assistance. Thanks.

kagbasi-ngc

@kagbasi-ngc I figured out what the problem was, so wanted to post it for the benefit of the community.

The root cause for me ended up being a firewall issue on the Windows Server where I was running the NFS server role. While I hadn't made any changes to the firewall, the profile of the network interface connected to the management network had changed from Domain to Public/Private, thus, Windows Defender Firewall applied the most restrictive settings since it saw that the NIC wasn't connected to the Domain profile (even though it physically was).

This post on Serverfault (https://serverfault.com/a/647201/189248) clued me in and I looked at the Network Location Awareness service (NLA). It was set automatic and was running, so I restarted it and this reverted the profile of the NIC back to Domain and caused Windows Defender Firewall to apply the previously configured rules.

It is important to note that this situation won't be common, as most of you won't be running your NAS on a dual-homed domain controller that is also running the DHCP server role. Hope this helps someone.

olivierlambert

Ahh good catch!! Thanks a LOT for taking time to share the solution, this might be very helpful for other member of the community having a similar problem!

kagbasi-ngc

@olivierlambert You're most welcome. XCP-ng + Xen Orchestra is a solid solution and I would very much like to see it get adopted within my organization, so I'll do anything (legal of course) to work through these problems and share the solutions, so the entire community can benefit.