@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!
Posts made by stevezemlicka
-
RE: XO user authentication - excessive and unknown tasks
-
RE: XO user authentication - excessive and unknown tasks
@julien-f
I updated to commit 3410c today and the issue is still present. -
RE: XO user authentication - excessive and unknown tasks
@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. -
RE: XO tasks - XO user authentication - too many?
@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-tasksI'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?
-
XO user authentication - excessive and unknown tasks
This is very similar to the following post:
https://xcp-ng.org/forum/topic/7865/xo-tasks-xo-user-authentication-too-manyHowever 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.
-
RE: Issues Mounting NFS Remote for Backups
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.
-
RE: Issues Mounting NFS Remote for Backups
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?
-
RE: Issues Mounting NFS Remote for Backups
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.
-
RE: Issues Mounting NFS Remote for Backups
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?
-
RE: Issues Mounting NFS Remote for Backups
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?
-
RE: Issues Mounting NFS Remote for Backups
I'm sorry for the delay, life happens huh.
Anyway, I don't see it here but i seem to recall someone asking what if I try to mount it at the same location as the backup is. I get an error that the location doesn't exist. The path that the most recent backup I setup is trying to mount to is:
/run/xo-server/mounts/7f13127e-3167-4cc1-921a-6dd955984899
However that path does not exist. I do not have /run/xo-server. My run directory looks like this:
atd.pid mdadm rpc.statd.pid tapback.36 blktap-control message-switch samba tapback.4 boottime.stamp mount screen tapback.5 chrony mpathalert.pid sepermit tapback.6 chronyd.pid mpathcount.sock setrans tapback.8 console multipathd sm tapback.master crond.pid netreport sm-notify.pid tapback.pid cron.reboot net-snmp sr-mount tmpfiles.d dbus nonpersistent sr-ref udev faillock openvswitch sshd.pid usb-scan.sock gssproxy.pid openvswitch.booted sudo user gssproxy.sock perfmon.pid sysconfig utmp initramfs plymouth syslogd.pid xapi_init_complete.cookie iscsid.pid portreserve systemd xapi.pid lldpad.pid portreserve.pid tapback.1 xapissl.pid lock reboot-required.d tapback.10 xapi_startup.cookie log rpcbind tapback.15 xen lvm rpcbind.lock tapback.18 xenstored mcelog-client rpcbind.sock tapback.2 xenstored.pid mcelog.pid rpc.statd.lock tapback.35 xtables.lock
And yes, I built this from sources. The process went smooth with no anomalies. What's weird is I can mount this NFS as a normal datastore and create virtual disks on there without issue. I suspect this would address the permissions question. Does the Orchestra Backup feature use a different "user" than the rest of Orchestra? Did I maybe miss something in the build process?
-
Issues Mounting NFS Remote for Backups
I am having issues mounting an NFS Remote store for backups using XO. I'm on XCP-NG 8.1 with xo-server 5.66.0 and xo-web 5.69.0.
The error I receive is as follows:
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
I am able to manually mount from shell (including the ability to write) using
sudo mount -t nfs -o vers=3 172.23.1.20:/VM /mnt/nfs-test/
I also am able to successfully mount this as a standard nfs SR without issue in XO. This device is a QNAP so I've done some digging into the issues surrounding that such as:
https://github.com/xapi-project/sm/issues/511But it seems as though this may not be the issue since showmount shows both columns (unless I missed something).
showmount -e 172.23.1.20 Export list for 172.23.1.20: /Public * /VM 172.23.1.17,172.23.1.16
I've also tried using vers=4 (which version 4 also works when mounting in XO as a standard nfs SR). What's weird with that is it seems to leave vers=3 in there and just appends ,vers=4 and I get a protocol error:
Command failed with exit code 32: mount -o vers=3,vers=4 -t nfs 172.23.1.20:/VM /run/xo-server/mounts/7f13127e-3167-4cc1-921a-6dd955984899 mount.nfs: Protocol not supported
Lastly, I've also created a folder at the root of the nfs share and tried to mount that but receive the same error:
Command failed with exit code 32: mount -o vers=3 -t nfs 172.23.1.20:/VM/backups /run/xo-server/mounts/7f13127e-3167-4cc1-921a-6dd955984899 mount.nfs: access denied by server while mounting 172.23.1.20:/VM/backups
I can't seem to figure out what I'm doing wrong here. This is my first experience with Xen and everything else seemed to go well...even passing through disks to FreeNAS. This seems pretty straightforward but I just can seem to get it working. Any help would be appreciated. TIA