@bond007fink I want to push back on the conclusion being drawn here.

There are multiple workarounds mentioned in this thread, and at least one other user has already pointed out that this behavior correlates with recent Microsoft updates. That strongly suggests a change in how Windows is laying out or flagging the filesystem — not a regression in FOG itself.

FOG does not implement NTFS.
FOG does not write partclone.
FOG orchestrates existing, well-established tooling to capture and deploy disk images.

When Microsoft changes disk metadata behavior in a way that causes ntfsclone/partclone to behave differently, that does not automatically make it a “FOG bug.” At best, it’s an upstream compatibility issue; at worst, it’s Windows leaving the filesystem in a state that violates assumptions those tools rely on.

For something to be classified as a FOG bug, it needs to meet at least one of the following:

• A regression introduced by a FOG code change
• Incorrect parameters being passed to the underlying tooling
• A failure in FOG’s logic that independently causes the issue

None of that has been demonstrated here.

If someone can provide

• A reproducible case across systems
• Debug runs showing FOG invoking tooling incorrectly
• Evidence that FOG’s behavior changed independent of OS updates.

then I’m happy to investigate it as a FOG issue.

But attributing “FOG needs to fix this” to what appears to be an upstream file-system behavior change isn’t accurate, and it doesn’t help move the problem toward an actual solution.

To be clear: I don’t mind helping fix problems - even upstream or compatibility issues - if there’s a clear, reproducible failure that can be attributed to something FOG controls.

What I do mind is hand-waving the problem away with “FOG needs to fix this” without showing:

• how to reliably reproduce it
• what changed that caused it
• or where FOG itself is behaving incorrectly.

Saying it works if I use an older image or it started after recent Windows updates is useful diagnostic information - but it points away from FOG being the root cause, not toward it.

If someone can demonstrate that:

• FOG is passing incorrect parameters
• FOG logic regressed
• or FOG can reasonably detect and mitigate a specific file-system condition.

then I’m happy to look at code or tooling changes.

Until then, attributing this to “FOG needing to fix something” is a conclusion without evidence.

@mmoore5553 Understood and appreciate the return with new information.

i’m not sure what caused it but glad it has since been addressed/fixed.

Thank you! And yes, I gave an upvote!

@mashina I’m not sure I understand what “problem” you’re actually seeing?

The TOKEN was written at x time, the SECTOKEN expires 30 minutes later, this is expected.

The REset Encryption token butten IS expected to show up so you can, well, reset the encryption token if needed.

This token is generated on a cycle, but there are potential cases where they become desyncronized.

Are you seeing a problem or just reporting something that was noticed?

@zzeuss1969 normally unable to find image store means the file/folder of that image does not exist. Can you check the image path in the Ui and verify that path exists on the fog server? Most likely it could be multiple things but based on what I can tell, it’s mounting nfs just fine, so I suspect a few things , image store (typically /images) does not have the folder and files for that image, or what you have as the “new” store is not being shared by the fog server.

@mmoore5553 We dont’ ahve any information, examples of the problem, anything beyond “What’s the issue”

Please provide more information as you have already clearly stated that there’s nothing that seems to be wrong with FOG at all, but rather something specifica to VM Workstation 17.

I don’t know what VirtualBox extensions have ot do with this, but Omnissa is it’s own thing (was VMware).

We don’t know what you’ve tried, if you’ve tried back with Workstation 16 and all works? You have just said “something’s broke, what is it?”

@rogalskij What you’re seeing is a list of all available kernels for download. The on that’s installed is the currently full release one. I don’t know which version that iss off the top of my head, but I believe it’s the October 14, 2025 at this point.

@rogalskij I believe this is expected to be honest.

The kernel version these are based off of is “Linux Kernel 6.12.35”

The date is when the FOS side built that specific kernel with whatever changes.

@Clebboii https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_MySQL#Database_Maintenance_Commands

Please see if this helps? Specifically the task related items. Sometimes stale (old/bad items suddenly show up from long ago.) admittedly I’d love to know what caused (or causes?) this but it has so far eluded me this far.

@chevengur The flag is onDemand -> 0 = No, 1 = yes.

@chevengur I believe you just check the box for perform immediately and dont’ define anythign against the cron side of things.

@AlexisPHC I’m hesitant to add such a feature.

While I can definitely see the appeal, I almost think this would be better as a plugin rather than an OOB nature of FOG as we’ve been around doing Quick Reg for quite a long time.

Now could this have been requested in the past and just missed? Absolutely.

I still think I would envision this type of thing more as a plugin (maybe even separating Quick registration as a whole) as a plugin.

Why?

All the features FOG does provide out of the box is quite extensive and difficult to manage at the best of times.

Now as to why quick reg, in it’s current state, is included in the baseline FOG? Because it’s more than just the UI interactions but also the FOS side of the house.

So the way Quick reg exists today in the FOS/UI would likely remain as is. As for adding new features? I think this is the part where it can be incorporated completely separate from the UI/FOS side as a plugin.

I have to think about how it could be done, but just wanted to give a base line thought process I have going on.

(Seeing at least what you’re requesting is more about the PHP side of things and managing them - including beign able to more generalize what kind of key flags could be used to name the device - more than just SYSSERIAL for example.)

Sorry for the bit of ramble, just the thoughts as I see them.

@AlexisPHC Ha, I’m faster than most would expect. lol

@AlexisPHC So i just took a few to look and figured it out. Please repull/install and all should work now.

Thanks for letting me know.

@AlexisPHC @JJ-Fullmer Are you able to test/help out on this?

I feel like this shouldn’t be a problem but I believe you’re the closest I have to who has been using the FOG Client consistently.

Thank you!

@AlexisPHC Yes

@AlexisPHC Can you please try a pull -> re-install and see if this is still happening?

I did have to create an “override” for the check, that is still secure (at least in hope).

@mashina pulling the update, and installing it, + the CTRL+SHIFT+R in the browser (once the install completes) should be sufficient.

@AlexisPHC Sorry, foujnd the issue and a fix is pushed.

In trying to allow for searching the value as part of things I inadvertently removed the “inputValue” field which is what is supposed to be what you can edit. I re-added that and left the ability to search based on the value information.

This should be fixed in the latest version. (You may still need to do a hard refresh as suggested, but should be able to edit the fields at least now.)

Thank you!

@AlexisPHC Can you please attempt a Hard refresh (CTRL + SHIFT + R in chrome) on your browser:

The “groups” are there (that’s what you see for the “BOLD” (FOG Boot Settings)

They are grouped still. The big difference is things are properly paginated which is a change to how things were done in the past.