Mounted NFS volume - Done, Failed to mount NFS Volume



  • I’ve used Fog before, but this is the first time I’ve tried the new version. It’s much prettier, I like it so far.

    I’m having a very hard time getting any image to upload to the server. It looks like it’s going to work, then it fails out.

    The host operating system is CentOS 7, and I can mount the NFS export just fine from the computer and read and write data to it, and a log is stored in journalctl of the event. When Fog mounts the volume, it doesn’t store -anything- in the log (As though it made no access attempt) and it fails out even though it says it mounted.

    I tried breaking it a bit by removing the export, and that failed as you would expect and put an entry in journalctl, but when it’s set properly it’s like something is getting missed.

    Untitled.png



  • That was it! .mntcheck was missing from /images/dev. Thank you!


  • Testers

    The section of code that generates that error is

    
      if [ -f "/images/.mntcheck" ]; then
        ...
      else
         handleError "Fatal Error: Failed to mount NFS Volume.";
      fi
    
    

    Is your .mntcheck still there? It is generated by the installer, but if you have recreated the /images directory it might be missing

    
      $ 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
    
    

    If they are missing, just regenerate them

    
      $ touch /images/.mntcheck
      $ chmod 777 /images/.mntcheck
      $ touch /images/dev/.mntcheck
      $ chmod 777 /images/dev/.mntcheck
    
    


  • 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.


  • Testers

    @p38fln, post: 33443, member: 2516 said:

    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.

    How are you confirming that it is actually mounted?


  • Testers

    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.

    
      $ mount -o nolock,proto=tcp,rsize=32768,wsize=32768,intr,noatime 10.0.0.36:/images/dev /mnt
    
    

    That will let you watch for errors on the NFS server without rebooting the client.



  • 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.



  • 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:

    ""

    If your machine is a test environment, simply drop fog db and reinstall :)

    Regards X23



  • 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?



  • 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



  • 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



  • Of course, see below:
    fogstoragenode.png



  • Hi,

    can we also see the configuration of the storage node?

    Regards X23



  • 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+found

    A 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.


  • Testers

    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.

    
      $ mkdir /tmp/images
      $ mount -o nolock,vers=3 192.168.222.100:/images /tmp/images 
      $ ls /tmp/images
     
        C652  client1  client3  dev  lost+found  opt  postdownloadscripts  teststretch  teststretch2
      $ umount /tmp/images
      $ rmdir /tmp/images
    
    

    Once you know that the NFS server is running properly we can move on to clients.



  • Hi,

    show me your /etc/exports contents

    Regards X23


Log in to reply
 

321
Online

38729
Users

10555
Topics

99938
Posts

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.