All versions of fog currently put only one storage node’s config into /etc/exports, normally, this is just /images

so the first thing is to check the exports file: /etc/exports. If an entry for your eternal drive isn’t there, just copy/paste the two existing lines and change the paths to point to the external drive.

Note that inside the external drive’s “images” directory, you need a “dev” directory.

/images/dev

also, in both /images and in /images/dev, you need a hidden file, named .mntcheck

you can create this file using the touch command, like this: touch .mntcheck

For future readers, the select statement that @ch3i posted can be converted into a delete statement like so:

DELETE hostName FROM hosts WHERE hostID NOT IN ( SELECT hmHostID FROM hostMAC );

Ok that tells me you only have /Data exported from your FOG server, I understand why the client can’t connect to the /images folder.

For full disclosure this is what I get when I run the following commands.

showmount -e localhost

Export list for localhost: /images/dev * /images *

cat /etc/exports

/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)

I’m going to recommend that you add the above two lines to your /etc/exports file.

Then run:

exportfs -r

Then run the showmount -e localhost command. This should then show you the exported /images directory.

yeah so i figured it out …
had a problem with the way i registered the machine … thanks for the help.

@george1421 said:

I assume that the FOG Project has some kind of feature requests system to request this function.

There is a feature request area in the forums.

@baboun said:

I understood that FOG should be the master node in the case of Multicast but with not enough space, how it works when I want to upload?

You can setup the storage nodes however you like.

The master node of a storage group does not have to be the fog server. It can be what you define it to be.

All uploads go to the master node of a storage group first, then are replicated to other storage nodes in the storage group - so keep that in mind.

For multicast to work, the interface name must be correct. It also has to be running Linux, so that the FOGMulticastManager can run and do the job. The interface name must be correct for multicast to work for that storage node.

So, you have options for the master node, it just takes configuration. While 1.2.0 is not as flexible with this, I’m sure it can be done.

I would also say its the physical disk based on what you have posted. I have experienced a bad sector on a hard drive cause ghost and clonezilla to fail. I have not yet experienced this with FOG (just because with the other I’ve deployed units in the 1000s).

I would ask 2 questions here.

What is the hardware you are deploying to (ie Lenovo M93, Optiplex 9010, etc) Have you physically replaced the hard drive in this system. (I noted that you mentioned hard drives . Do you have more than one in this system?

@alireza
I suppose you’d mount the ISOs for those as read only using the DBAN example I mentioned in the other thread, and then locate the kernel and init, and just chain to it using the fog boot menu.

@Uncle-Frank I remotes in with Joseph last night. We fixed the issue. Basically he had a link in www and www/html. They both pointed at each other which was causing the problem.

@Tom-Elliott said:

You are running legacy client, so you would have to update all of the clients to receive these new configs?

set the interval for checkin
reinstall the legacy client on a computer.
copy C:\Program Files (x86)\FOG\etc\config.ini
push that file out as an update…

There is an option here:
Service Configuration -> Client Updater

This area will allow you to push out the new config.

@mike4realz Look through this thread: https://forums.fogproject.org/topic/5998/new-server/5

The senior dev posted commands to set the permissions correctly.

Beyond this, we need details… like OS, Version of FOG, and any other relevant information.

@Joseph-Hales I agree with the plan to solve the thread but not for the reasons you describe, rather for the fact this was likely somewhat related to the issues found earlier.

@Tom-Elliott Almost there actually…The errors mentioned are no longer present; however all nodes show options like server (ie. Multicast,Image/Snapin Replication etc.) and all present “no data to read” when chosen.

Thanks for the hard work, I’ve mentioned it before, but I feel it needs said again. I really appreciate your help.

I’m thinking it was cache related as a refresh got it fixed.

Please ensure that if you are not using resizable image types, that the source HDD for the image is smaller or exactly identical to the destination HDD.

You cannot change the image type and it simply take effect. After changing the image type, you must re-upload.

If this does not work, use DBAN or other boot and nuke programs to quickly “zero” the source HDD, and then recreate the image and re-upload.

I was really strongly wanting to see this thread solved…

I apologize for the delay in this. I am not only managing the bench but am testing the imaging software solutions as well. We have found that FOG will not work correctly for our environment and had to pass on it. There is no problem with the software, it simply does not fit our environment. Thank you for your replies and for the FOG project!

@Tom-Elliott Sorry for the delay in posting an update on this. On a whim, I pressed the “upgrade” option on the system update page to take it up to 14.04. Didn’t really think it would work, but if I’m going to start over, why not try. You were right. The newer version fixed the problems I was having. Downloaded the latest trunk version, and we’re off and running. Thanks again

@Rusty Great to hear that you got things sorted. I am marking this solved for now. You are more than welcome to post a more detailed article about this here. Or get in contact with us so we can add this to the wiki! Thanks.

@OvandHo Issue solved?