Mounted NFS volume - Done, Failed to mount NFS Volume
-
There are a bunch of changes in NFS (and everything else) waiting in CentOS 7, not sure which ones have been integrated with fog yet. As X32 said, you should give us your /etc/exports and maybe check NFS mounts on the fog server itself, e.g.
[CODE]
$ mkdir /tmp/images
$ mount -o nolock,vers=3 192.168.222.100:/images /tmp/images
$ ls /tmp/imagesC652 client1 client3 dev lost+found opt postdownloadscripts teststretch teststretch2$ umount /tmp/images
$ rmdir /tmp/images
[/CODE]
Once you know that the NFS server is running properly we can move on to clients. -
Contents of /etc/exports
/images *(ro,sync,no_wdelay,insecure_locks,no_root_squash,insecure,fsid=1,)
/images/dev *(rw,sync,no_wdelay,no_root_squash,insecure,fsid=2,)
/mnt/isos *(rw,no_root_squash)The 3rd export isn’t for Fog. All 3 of the exports work just fine for anything other than the Fog clients - I tried an OptiPlex 345 and a ESXi 5.1 Virtual machine for the Fog image and both of them failed exactly the same way.
CentOS 6.5 system connecting to the NFS export -
[root@localhost /]# mount 10.0.0.36:/images /mnt/images
[root@localhost /]# cd /mnt/images
[root@localhost images]# ls
dev lost+foundA log entry is created in journalctl when I connect this way, and a log entry is also created if I try to connect to a directory that isn’t exported. There are no log entries at all when Fog tries to connect and the directory is properly exported, but if I remove the export I get an error that the directory isn’t exported.
-
Hi,
can we also see the configuration of the storage node?
Regards X23
-
Of course, see below:
[ATTACH=full]1174[/ATTACH][url=“/_imported_xf_attachments/1/1174_fogstoragenode.png?:”]fogstoragenode.png[/url]
-
Hi,
oh you touched the defaultmember? afai remember this is not good.
Have you tried to leave it untouched and add an additional storage node?Regards X23
-
I was mistaken, it is creating entries in journalctl when the client connects to the server
Jul 17 11:39:46 localhost rpc.mountd[2506]: authenticated mount request from 10.0.0.141:939 for /images/dev (/images/dev)
Jul 17 11:39:29 localhost in.tftpd[29884]: tftp: client does not accept options
Jul 17 11:39:29 localhost xinetd[994]: START: tftp pid=29883 from=10.0.0.141 -
I tried to put it back to how it was but if you can tell I touched it obviously did something wrong - what should it look like?
-
Hi,
iam not sure if it’s harmful to edit the defaultmaster, just an idea.
This one here is untouched except the storage node name:[IMG]http://i.imgur.com/zD43ETj.png[/IMG]
If your machine is a test environment, simply drop fog db and reinstall
Regards X23
-
I dropped the fog db and reinstalled and the DefaultMember configuration looks exactly the same as before, and same errors - It mounts the NFS volume, then says it isn’t mounted.
-
You can schedule a debug tasks for one of the clients and boot into the imaging environment. Under “Basic Tasks” for the client you are trying to image select “Advanced”, then “Debug task”, when the client finishes booting it will leave you at a shell. Try the mount command manually from there, e.g.
[CODE]
$ mount -o nolock,proto=tcp,rsize=32768,wsize=32768,intr,noatime 10.0.0.36:/images/dev /mnt
[/CODE]
That will let you watch for errors on the NFS server without rebooting the client. -
[quote=“p38fln, post: 33443, member: 2516”]I dropped the fog db and reinstalled and the DefaultMember configuration looks exactly the same as before, and same errors - It mounts the NFS volume, then says it isn’t mounted.[/quote]
How are you confirming that it is actually mounted?
-
All I can go on is it says Mounted NFS Volume - Done as it boots up.
I tried running the mount command in the shell as you suggested, it worked fine and I was able to view the contents of the /images/dev directory and open a file and delete a file from the client.
-
The section of code that generates that error is
[CODE]
if [ -f “/images/.mntcheck” ]; then
…
else
handleError “Fatal Error: Failed to mount NFS Volume.”;
fi
[/CODE]
Is your .mntcheck still there? It is generated by the installer, but if you have recreated the /images directory it might be missing
[CODE]
$ ls -l /images/.mntcheck
-rwxrwxrwx. 1 root root 0 Jul 5 22:04 /images/.mntcheck
$ ls -l /images/dev/.mntcheck
-rwxrwxrwx. 1 root root 0 Jul 5 22:04 /images/dev/.mntcheck
[/CODE]
If they are missing, just regenerate them
[CODE]
$ touch /images/.mntcheck
$ chmod 777 /images/.mntcheck
$ touch /images/dev/.mntcheck
$ chmod 777 /images/dev/.mntcheck
[/CODE] -
That was it! .mntcheck was missing from /images/dev. Thank you!
