Mounting a NFS remote for metadata export fails on FreeBSD

[bfjmg]

First off thank you all for your great work.

Following the "from the source' section in the guide, I installed xen-orchestra (5.50.1) on a FreeBSD 12 VM. This worked fine. However mounting a NFS storage for the metadata backup fails on the FreeBSD based XO VM, due to different syntax of the mount command in Linux and FreeBSD. I implemented a patch, which I would like to give back upstream. This patch has been tested with the following versions:

• XO origin: the sources
• Versions:
  • Node: v8.16.0 - v10.19.0
  • xo-web: 5.50.1 - 5.59.0
  • xo-server: 5.50.1 - 5.59.0

Expected behavior

Mounting a remote via NFS for the metadata backup should work on FreeBSD too. Therefore xen-orchestra might use the output of uname (which can be retrieved via os.type()) to set the right arguments for mount.

For linux the mount arguments are

['-t', type, device, realPath, '-o', options]

, for *BSD however

['-o', options, '-t', type, device, realPath]

The issue seems to be in xen-orchestra/@xen-orchestra/fs/src/_mount.js.

Current behavior

Mounting a remote via NFS on a FreeBSD based XenOrchestra VM fails, and the logs show an error regarding the usage of the mount command (see excerpt below).

{
  "code": 1,
  "stdout": "",
  "stderr": "usage: mount [-adflpruvw] [-F fstab] [-o options] [-t ufs | external_type]
       mount [-dfpruvw] special | node
       mount [-dfpruvw] [-o options] [-t ufs | external_type] special node
",
  "failed": true,
  "signal": null,
  "cmd": "mount -t nfs 192.168.1.10:/mnt/metadata /run/xo-server/mounts/62370e07-0f02-4c74-a7ba-8aa3885a75a8 -o vers=3",
  "timedOut": false,
  "killed": false,
  "message": "Command failed: mount -t nfs 192.168.1.10:/mnt/metadata /run/xo-server/mounts/62370e07-0f02-4c74-a7ba-8aa3885a75a8 -o vers=3
usage: mount [-adflpruvw] [-F fstab] [-o options] [-t ufs | external_type]
       mount [-dfpruvw] special | node
       mount [-dfpruvw] [-o options] [-t ufs | external_type] special node

",

[julien-f]

Fixed by #4989