Did you build your Windows 10 image from scratch or are you using a modified version of the pre-installed os?
You could try wiping the drive of all partitions, adding a blank one and imaging again. We have had trouble with partitions on the disk that were put there as a factory recovery point. (I know Dell, HP, etc are known for having a recovery partition).
The problem above is on the CLIENT end, not there server…server is okay from what I can tell
The server wasn’t OK at the time I posted what I did, it was out of space. This was not a fresh install of Ubuntu 16 /w fog if you were already out of space. The title of this thread should be changed.
@george1421 Yeah, maybe that was it - just a cold boot after the BIOS update to 'bed things in". Like I said, I was stunned to see the NUC suddenly behaving, so I went back in to BIOS and undid my changes to confirm if that was the cause - still boots w/o issue.
I recall there being a Wiki page somewhere listing hardware that is known-to-work with FOG. Would be good to update that with this information. Not sure if this account has permissions to update…otherwise I’ll create a new one.
@Faheem FOG 1.3.0 has no official API (Our 2.0 rewrite changes this, but it’s not ready for production). A quick look over that github repository seems to indicate that the api-wrapper simply crawled / interfaced the web portal, which has definitely changed in the past 3 years.
@george1421 this can be seen when imaging two hosts at the same time via unicast.
I guess I’ll have to take your word on this because I looked at the config files again and it looks like he is mounting 172.31.161.246:/volume1/images over /images in the fstab on the FOG server and then sharing out /images on the fog server in the /etc/exports file. The last time I tried that showmount -e 127.0.0.1 showed no shares. But that was a while a go. I was trying to work on a way to create a skinny fog server VM with all files stored on an external NAS. That didn’t work so well.