Skip links

VCD Backend validation of NFS failed with: is owned by an unknown user

Mounting an NFS datastore from NetApp storage array fails with an error message during the initial VMware Cloud Director appliance configuration.
Backend validation of NFS mount failed with: /opt/vmware/vcloud-director/data/nfs-test/test-file is owned by an unknown user with UID 4294967294: expected root

Issue

As you know setting up VMware Cloud Director requires an NFS share, both for the initial configuration and for clustering purposes.

During a recent 10.3.2 fresh install for a customer I ran into an issue when trying to set up a brand new VCD appliance. As part of the initial configuration wizard you enter the details of your NFS export which causes VCD to carry out a validation check.  It was during this check where I got the following error:

VCD NFS Error

Initially this looked like it was the actual VCD appliance. Looking in the location mentioned there was no such file.

The issue itself seems to be occurring with installations using version 10.3 when using NetApp NFS exports and is listed under the known issues section of the release notes.

 

Resolution

As of now there is no permanent fix. The release notes mention a workaround: “Configure the VMware Cloud Director appliance by using the VMware Cloud Director Appliance API.”

Steps required

Log into the primary cell using SSH and the root user.

Create a file called primary-setup.json in the /tmp folder

Paste the following text in and change the relevant sections for your environment

{
"applianceType": "primary",
"storage": {
"nfs": "sto-nfs02.terataki.local:/vcdnfs"
},
"appliance": {
"dbPassword": "VMware12345!",
"ceip": false
},
"sysAdmin": {
"username": "administrator",
"password": "VMware123!",
"fullName": "Terataki cloud administrator",
"email": "vcd103@terataki.local"
},
"installation": {
"name": "VCD Lab",
"id": 1
}
}

Run the following curl command referencing the file from the CLI

curl -k -H "Accept: application/json" -H "Content-Type: application/json" -u "root:MyPassword" -X POST "https://localhost:5480/api/1.0.0/systemSetup" -d @/tmp/primary-setup.json

The initial setup will proceed and after a few minutes you will be able to access the deployed Appliance normally. If you only require the primary cell then you are good to continue your configuration within the UI.

If you have additional standby cells to add to the cluster follow the below steps to bypass the NFS validation check

For the standby cells create a file called standby-setup.json

Paste the following in and ensure you are using the correct NFS

{
"applianceType": "standby",
"storage": {
"nfs": "sto-nfs02.terataki.local:/vcdnfs"
}
}

Run the curl command from the CLI referencing the standby-setup.json

curl -k -H "Accept: application/json" -H "Content-Type: application/json" -u "root:MyPassword" -X POST "https://localhost:5480/api/1.0.0/systemSetup" -d @/tmp/standby-setup.json

Give the cell a few minutes and you will find that the node has been added to the cluster.

Leave a Comment

  1. did the permissions of the file “primary-setup.json” need to be changed?

    1. Hi Keith

      No we didnt need to change the permisson. As it was created as root it had the correct permissons to be read stright away.

  2. What about Cell Application only? Is it Cell, Cell Application?

    “applianceType”: “cell”,
    “storage”: {
    “nfs”: “sto-nfs02.terataki.local:/vcdnfs”
    }
    }

      1. That worked thank you! FYI this is happening in our 10.3.3 environment.