Just tested, that was it. It was a 10 second fix to something I spent hours on. Well if anyone comes across this and is able to mount NFS storage pools successfully but cannot mount Backup Remotes, check that the Orchestra server itself (not the xcp-ng server) is on your NFS host ACL.
Thanks to everyone who took the time to read this and especially to those that responded.
@julien-f
Awesome, thank you for the update. So if I'm hearing you correctly, this seems to be more of a minor annoyance and not necessarily anything harmful or detrimental. Thank you for verifying this is on the roadmap. I'll hang tight until it is patched. Thank you for all your work and efforts on this project!
@julien-f
I updated to commit 3410c today and the issue is still present.
@olivierlambert
I was originally using commit 1fac7. I reinstalled/upgraded today to 339d9 and the issue is still present. One interesting thing is these "started" tasks disappear when the page is refreshed.
@Darkbeldin
I started another topic because it seemed like there were some differences in my issue than was described here. However there are significant similarities too.
https://xcp-ng.org/forum/topic/7881/xo-user-authentication-excessive-and-unknown-tasks
I'm having this on xo-server 5.124.0, xo-client is 5.126.0 with a fully patched XCP-ng 8.2.1. You mention this being fixed recently. Any idea which specific version this was patched on and how it compares to the versions I listed?
This is very similar to the following post:
https://xcp-ng.org/forum/topic/7865/xo-tasks-xo-user-authentication-too-many
However there are a few differences that may warrant creating a new topic with reference to the old. Like the other topic, I am getting excessive "XO user authentication" tasks. However one difference is, when clicking on the "Open raw log" option, I just receive a "not found" page (not a 404 error but rather a page that simply displays the text "not found") and when I click cancel I receive a dialog from the cancel operation stating "Not Found". Additionally, most the tasks in question have a status of "started" and are yellow rather than green. Finally, I have performed a xcp-ng and xo server reboot with no change.
This is a new and freshly compiled XO instance from last night. xo-server is 5.124.0 and xo-client is 5.126.0. I'm on fully patched XCP-ng 8.2.1.
Did I do something wrong? Is this a known issue? Any thoughts on what might be causing it? Is there additional information I can include? I'm currently tailing some of the logs on the hypervisor including xensource.log but I'm not entirely sure what would be helpful.
Just tested, that was it. It was a 10 second fix to something I spent hours on. Well if anyone comes across this and is able to mount NFS storage pools successfully but cannot mount Backup Remotes, check that the Orchestra server itself (not the xcp-ng server) is on your NFS host ACL.
Thanks to everyone who took the time to read this and especially to those that responded.
Before I head down that path, does that make sense? Is it the case that when you mount an nfs storage pool, Orchestra triggers xcp-ng to mount that which is why I could mount and create virtual disks. Whereas the Backup Remote is mounted by the Orchestra server rather than directly from xcp-ng? Or is that not the case...or do i just need to RTFM here?
I'm stupid. I forget that Orchestra is not running on the xcp-ng server (which I wish it did btw). I think I need to add the Orchestra server to the NAS allow list. Ugh, i can't believe how much time I spent on this for such an obvious oversight.
Is it the fact that I am running that with sudo in a terminal? Do I need to change something so Orchestra can do that without sudo?
I manually created the directory structure that the backup\remote store was trying to use and manually mounted the nfs to that. I verified that all the settings for the remote datastore matched. I can, in terminal, see the test data in the mountpoint. Running the backup with the NFS already mounted produces the same error.
Command failed with exit code 32: mount -o vers=3 -t nfs 172.23.1.20:/VM /run/xo-server/mounts/7f13127e-3167-4cc1-921a-6dd955984899 mount.nfs: access denied by server while mounting 172.23.1.20:/VM
Now I suspect if it needs to mount the store itself, it will fail if I already have it mounted to the location it wants to use. But what I don't get is, from a terminal, I can sucessfully run:
sudo mount -t nfs -o vers=3 172.23.1.20:/VM /run/xo-server/mounts/7f13127e-3167-4cc1-921a-6dd955984899
but it seems to me, this is what the backup is trying to run unsuccessfully. What am I missing here?