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

    cannot mount NFS remote

    Scheduled Pinned Locked Moved Xen Orchestra
    solved
    2 Posts 1 Posters 533 Views 1 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.
    • D Offline
      djingo
      last edited by djingo

      I am failing to configure a NFS remote for backups.

      Situation: I have already read all forum articles on this, and still do not have the solution.

      Setup: XO from source running as root in a container with SYS_ADMIN capability on a docker host on a different hypervisor, not any of the XCP-ng hosts. NFS export on an unraid server.

      Error messsage:

      Command failed with exit code 32: mount -o defaults -t nfs unraid:/mnt/user/backup-xcp-ng /run/xo-server/mounts/ea17b....
      mount.nfs: access denied by server while mounting unraid:/mnt/user/backup-xcp-ng

      What I have tried so far:
      I know that the XO machine must be able to mount from the NFS server, not the XCP-ng host. The NFS share settings are so that the docker host where runs XO is able to mount. If I run showmount -e unraid or the mount directly on the XO docker host it works and I can see the packs for both operations on the network.

      However, if I run showmount -e unraid and try the mount command within the XO container, only showmount works and I can see the RPC and MOUNT packets on the network, but no packets for the mount command!

      So clearly this is a problem with the container, the mount command does not even reach out to the network (although running as root and with SYS_ADMIN capability).

      What could be the problem?

      1 Reply Last reply Reply Quote 0
      • D Offline
        djingo
        last edited by

        OK I got it. I didn't think that the host was using apparmor, but it actually does.

        So it must be started using --cap-add sys_admin --security-opt apparmor:unconfined

        Now it works.

        1 Reply Last reply Reply Quote 0
        • First post
          Last post