@george1421 Here is what shows up as mounted on the storage node:

Firewalld stopped and disabled.
sestatus is in permissive mode.

@george1421 I had a meeting this afternoon and will be off the next few days, so I won’t be able to test this until Monday. I will post results when I get in.

@george1421 Okay. I was issuing the debug task from the web GUI instead of deploying an image with debugging.
So, when I try mounting the volume before running the fog command, I get denied:

However when I then run the FOG command the imaging goes without a hitch:

After the imaging completes the share is mapped no problem.

@george1421 Here is a pic of the first command… the 2nd command brought back an empty result on the surface:

The storage node IP is 10.59.181.12.

@george1421 They are just load sharing. The devices being imaged are on a different subnet than the storage nodes and fog server. Network team said there should be no blocking between sites on the firewall or the switch configs.

@Sebastian-Roth Here’s what I get when trying to debug on my surface when I try to run the fog command on the debug. It doesn’t even make it past the first step.

@Sebastian-Roth maybe… I know our network team has been tightening up security. Our main FOG server and our storage nodes are all set up with link aggregation (NIC teaming with LACP) with dual Gigabit ports. However the LAG setup didn’t seem to have issues previous to the 1.5.6 update.

So I have had the following issue for the last few months and haven’t been able to figure out what’s going on. The issue seems to only be with any of my windows 10 images, including ones I have just created… and only on the 1st attempt FOG takes to image the machine. After the client machine reboots from the error it images just fine. The error is that it is unable to locate the image store (/bin/fog.download).

Based on searches it seems to be an issue with FTP… I did notice that somehow my deployment server now has both a “fog” and a “fogproject” user account that it uses. I have to use one for my storage node settings and the other for the FTP username and password under the TFTP settings. If I try to use one account or the other for both I can no longer update my kernel and other functions break.

The only thing I can think of is that somehow things got screwy when I went from being on some test builds for troubleshooting last year back to a stable build when 1.5.6 came out.

Any suggestions for fixing this is greatly appreciated.

@buercky Awesome! Glad to hear it’s working now.

@buercky So, I see one thing in your screenshot that concerns me… you have two option 66 with one as the ipxe.efi instead of your server IP. Here’s what my DHCP options look like after applying the options from the guide: