SOLVED How to create subfolders in a storage node

  • In the old version, I can create new storage nodes by creating a subfolder in /images folder, so I can separate my FOG images for different computer labs. But ever since I upgraded FOG to the latest 1.3.4 version, it no longer works with the subfolder setting, I can only upload the images to the root /images folder.

    Here is my /etc/exports file:
    /images *(ro,sync,no_wdelay,no_subtree_check,insecure_locks,no_root_squash,insecure,fsid=0)
    /images/dev *(rw,async,no_wdelay,no_subtree_check,no_root_squash,insecure,fsid=1)
    /images/CLAB *(ro,sync,no_wdelay,no_subtree_check,insecure_locks,no_root_squash,insecure,fsid=0)
    /images/CLAB/dev *(rw,async,no_wdelay,no_subtree_check,no_root_squash,insecure,fsid=1)

    And I have .mntcheck file under /images/CLAB/dev folder, but at the end of the upload process, it will say it couldn’t find the uploaded file, and I noticed that the uploaded file is actually saved under /images/dev instead of /images/CLAB/dev

    I hope this problem can be resolved since I have 60+ image files, it will be more organized if I can put them in different subfolders. And this used to work with the old version…

  • @Tom-Elliott @george1421 - Here is the latest news.

    I removed the mount points on the server in /etc/exports
    so they only show

    0_1495714432985_Screen Shot 2017-05-25 at 8.13.42 AM.png

    I uploaded an image to /images/vol1/… (and it looks successful


    However, after looking into the restart on the server, the image file copies the name only with 0 kb.


    Then after the temp files remain in /images/dev/macaddress, ect. and don’t move.

    0_1495714539402_Screen Shot 2017-05-25 at 8.09.29 AM.png

    Now, I am confirming that a “directory” outside of a directory volume in /images/sample do work properly. Where as /images/sample is the directory with the proper rights.

    0_1495714617956_Screen Shot 2017-05-25 at 8.16.33 AM.png

    Image is complete and computer restarts


    Then the image is moved correctly into the directory /images/sample

    0_1495714811668_Screen Shot 2017-05-25 at 8.19.55 AM.png

    My other thoughts are that I may try. Is it an ext4 thing or should I go back to ext3, and try it.

    Let me know know what you think. I am willing to work with you guys for the success of this project as always! Thank you

  • Senior Developer

    I need to rethink things.
    That said, however, you shouldn’t need to export the new mount point.

  • Moderator

    @sdm42doc selinux is disabled on these servers, right? or at least set to permissive. I would think you would have had other issues if selinux was stepping on things.

  • Moderator

    @sdm42doc Are you getting the same error as in this post with your home kit where you didn’t try to setup the storage node bits?

    I can/will also duplicate with our dev lab at the office tomorrow. I can more closely emulate what you have with that environment.

  • @george1421 this is one of those weeks, my testing was as follows

    1> physical hardware rack fog server with raid controller mirror raid with volumes / and /vol1 ubuntu 16.04.02 fog 1.4.0
    2> esxi hosted fog server with two volumes / and /vol1 ubuntu 16.04.02 fog 1.4.0

    tomorrow, I am going to do a fresh install on esxi, and test it accordingly and try to triplicate it and I will report back.

  • Moderator

    @sdm42doc (thinking out loud) Yet imaging fails with the error screens you posted…

    FTP works, can navigate to, can create directories
    permissions are set correctly
    captured images going to /images/dev/<mac_name> but not being moved to /images/vol1/<image_name>
    Using Ubuntu 16.04.02 with current version of FOG 1.4.0
    Works with /images/vol1 as a directory not as mounted volume
    == should be working

  • @george1421 I can walk around and upload files from my desktop, create directories, ect all through that HD marked vol1 logged in as fog through ftp.

  • Moderator

    @sdm42doc you have them correct. Did you try with the external ftp client yet?

    I’d like to duplicate this with my home lab, but my esxi server is down with a failed power supply (one is on its way from amazon). All I have right now is my FOG-Pi server so I can’t really add a second drive to that to duplicate what you are seeing.

  • @george1421 I believe I have the rights correct, as attached, maybe you will see something I missed. I appreciate all your help!

    0_1495674153010_Screen Shot 2017-05-24 at 9.01.58 PM.png

  • Moderator

    @sdm42doc We can test without imaging easy

    Mount up that new drive to the vol1 mount point under /images

    Then from an external computer ftp to the fog server using the user ID and password that is defined in the /opt/fog/.fogsettings file.

    Navigate to the /images/vol1 directory and make a directory using the ftp client (like from a ms windows box). If you can make the directory then imaging should work. That is what the FOS engine does. It captures the image to /images/dev/<mac_address> then when done it moves the files using FTP to /images/<image_name>

  • Moderator

    @sdm42doc Yes it was a directory, but that should work the same as the mount point for a hard drive.

    Are the permissions set correctly on that mount point after its mounted?

  • @george1421 is your vol1 a directory in the /images or a separate hard drive. Mine is a separate hard drive /dev/sdb mounted to /images/vol1 when i made a directory, your right it did work fine. just not a directory mounted

  • Moderator

    @george1421 Well I have sad news, it worked for me.

    All I did was create a directory under /images (called vol1). The path was /images/vol1 I did change the owner to fog.root Then I setup a new image and set the path to vol1/WIn7Test and then assigned that image to a virtual box VM I have. It captured the image correctly and moved it to the /images/vol1/Win7Test directory correctly.

  • Moderator


    So I tried it on my home lab, and have no good results. I don’t think it is going to work.

    If we can trap the error we can get it fixed, so don’t give up hope on this.

    Just for clarity you created the vol1 in images before you imaged the computer? (this is was a sticking point during my discussion with the devs). I’ve got 1.4.0 setup in my home lab, let me see if I can duplicate your results.

  • So I tried it on my home lab, and have no good results. I don’t think it is going to work.

    The uploads go up to /images/dev then only move the image name with 0MB to the /images/vol1/ folder, the other files stay in /images/dev/0050569fb7e7 d1p1.img, ect. but it looks like the image completed with no errors.

    0_1495670861881_Screen Shot 2017-05-24 at 7.46.37 PM.png

    0_1495670944373_Screen Shot 2017-05-24 at 8.08.46 PM.png

  • I didn’t read the whole thread, just the title. Another guy tried doing this but it ended up not working, I told him to undo it.

  • Moderator

    @sdm42doc This looks like you might have a storage node configuration still in place. If you look at your last image its using the /image as the root, but the error messages in the next from the bottom its trying to move the file from /images/vol1/dev (but the image is in /images/dev).

    The first picture shows that you have the right shares in place for the secondary nodes.

  • @george1421 attached is the screen shot from the fog box.

    0_1495664599577_Screen Shot 2017-05-24 at 6.21.05 PM.png

    I also replicated all of the interiors of the files as outlined, copying the /dev/ files to the vol1/ ect.

    On upload, it looks like all is well, the image is going to /images/dev/(mac address of machine) then on the final write, it fails, as attached.

    I am going to try to recreate this issue in my home lab tonight.



  • Moderator

    @sdm42doc Just for clarity what I posted below didn’t work for your setup?

    If not can you provide the output of these commands

    1. df -h
    2. showmount -e

    I talked with the developers for quite a while and they were positive it would work as I outlined.

    If you setup a storage node route, you need to duplicate the /images base structure below on the new volume. I won’t probably have time tonight to test this in my dev environment but I will get to it tomorrow night.