@mrawesome987 Looking at my dhcp server configuration and comparing it to the wiki. I have my policies defined at / on the scope and not on the ipv4 global level. I had to it that way because we didn’t want the dev environment to be ruled by what we have in production. I know this works because we use it every day when pxe booting both bios and uefi systems.

@george1421 That did the trick!

I had previously added the images2 *(ro etc;etc;etc;) but did not run the sudo -exportfs -a command.

I knew it was something simple. Thanks so much for your help!

@tomtom2770 So let me discuss what FOG needs to work in your environment.

The master node is kind of the brains of the FOG system since it houses the fog database.

The storage nodes are disk storage for deploy only. It needs to be in contact with the FOG server 100% of the time for the storage node to remain functional.

So lets say you have 1 sites HQ and SiteA. You have a master node at HQ and a storage node at SiteA. At SiteA you have the dhcp options to point to the local storage node and the needed boot file.

You pxe boot a target computer at SiteA. It downloads the boot file from the local storage node and iPXE starts up. Then iPXE reaches out to the local storage node to download default.ipxe file. That file points to your master node boot.php script which builds the iPXE Menu. If the computer isn’t registered, when you select register it will download FOS Linux (over the wan) from HQ to the target computer. (once the computer is registered and associated with a location, the storage node will be used for all other file transfers).

Now if you have the fog client installed on the target computer it will only talk to the master node to get instructions (install snapin, update inventory, etc). If the target computer get an instruction to install a snapin, that snapin is downloaded from the local storage node.

So the point here is that the HQ fog server is important here and must be at a fully routable location from all remote sites.

If your site to site VPN ever goes down so does FOG imaging. Depending on your goal, number of client computers, and stability of the VPN network, you might want to install a full fog server at each location.

@danieln Have you tried imaging that exact same machine from both servers and you only get the “No such file or directory” error on the later one?

And asking again, do you have another notebook - exact same model - that you can deploy to, just to see if you get the same ATA errors?!