XCP-ng
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    Issues Mounting NFS Remote for Backups

    Scheduled Pinned Locked Moved Solved Xen Orchestra
    12 Posts 5 Posters 5.4k Views 2 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • S Offline
      stevezemlicka
      last edited by

      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?

      1 Reply Last reply Reply Quote 0
      • olivierlambertO Offline
        olivierlambert Vates 🪐 Co-Founder CEO
        last edited by

        Mounting might require some extra permissions, depending on your system configuration. So it's tricky to answer because this is your own system/environment.

        1 Reply Last reply Reply Quote 0
        • S Offline
          stevezemlicka
          last edited by

          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?

          1 Reply Last reply Reply Quote 0
          • S Offline
            stevezemlicka
            last edited by

            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?

            1 Reply Last reply Reply Quote 0
            • olivierlambertO Offline
              olivierlambert Vates 🪐 Co-Founder CEO
              last edited by

              Please read the doc: https://xen-orchestra.com/docs/from_the_sources.html#sudo

              1 Reply Last reply Reply Quote 0
              • S Offline
                stevezemlicka
                last edited by

                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.

                G 1 Reply Last reply Reply Quote 0
                • S Offline
                  stevezemlicka
                  last edited by

                  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?

                  1 Reply Last reply Reply Quote 0
                  • S Offline
                    stevezemlicka
                    last edited by

                    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.

                    P 1 Reply Last reply Reply Quote 2
                    • G Offline
                      geoffbland @stevezemlicka
                      last edited by

                      @stevezemlicka Thanks for mentioning this and reporting your "mistake" on the forums. I had been banging my head against the wall for a day before finding this post and realising the obvious.

                      1 Reply Last reply Reply Quote 1
                      • P Offline
                        procheeseburger @stevezemlicka
                        last edited by olivierlambert

                        This post is deleted!
                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post