@Tom-Elliott When searching for a solution I recall seeing a related post on GitHub but that was not me. Today I created a new VM that was 70GB with 2GB EFI partition and after sysprep and it yielded the similar resize error during capture.

I then tried Windows 11 25H2 June 2026 Build 26200.8655 with 60GB VM and it generated the resize error. 25H2 with 60GB VM and 2GB EFI also generated the resize error after sysprep during capture.

The AI suggested defrag C : /X

I ran the defrag before sysprep and capture was succesful.

The pre optimization total fragmentation was 22% and post defragmentation it was also 22%

To my understanding the /X flag consolidates free space. How was this the solution to my issue?

Per the FOG Project wiki I found that defrag is recommended before sysprep:

"…
Before Running Sysprep
Other steps to consider are:

Run Chkdsk /f /p prior to imaging
Defrag the drive
Make sure 2gb of disk space is free or the NTFSresize will fail
Make sure the FOG service is installed and properly configured
Update your hostnamechange.dll file
…
"
https://wiki.fogproject.org/wiki/index.php/Client_Setup

@kratkale What you see in the text field are place holders, just example views, if you were to hit update/save, those things aren’t what will be set.

THe reason you see “(varies)” is because the hosts in the group have some things where their host Primary Disk is set, but not all hosts have the same values.

As for your odd snapin issues please try these commands on the Database:

delete from snapinAssoc where saSnapinID <= 0; delete from snapinTasks where stSnapinID <= 0;

As for the domain join issue:

The “captured” host should not be joined to the domain until after the image has been captured.

The error you were seeing was joining domain “Code = 87”

That is not FOG writing an erroneous error, but rather the error from the Domain controller directly.

This may mean your environment is expecting to be set to a specific OU within the domain?

https://forums.fogproject.org/topic/11971/unable-to-join-domain-error-87

This is an old (albeit similar) topic with the same type of error you had seen so maybe it’s fix may help your fog client as well?

This, of course, isn’t strictly necessary, since your snapin method appears to be working anyway.

As always, please update to the latest and greatest as it should help with the prevention of odd jobs just getting created as well. After you clean up things of course.

Thank you!

@Tom-Elliott yes, I checked the services, they all running.
systemctl status nfs-server
● nfs-server.service - NFS server and services
Loaded: loaded (/usr/lib/systemd/system/nfs-server.service; enabled; preset: enabled)
Drop-In: /run/systemd/generator/nfs-server.service.d
└─order-with-mounts.conf
Active: active (exited) since Tue 2026-06-30 09:06:50 UTC; 17h ago
Process: 4995 ExecStartPre=/usr/sbin/exportfs -r (code=exited, status=0/SUCCESS)
Process: 4997 ExecStart=/usr/sbin/rpc.nfsd (code=exited, status=0/SUCCESS)
Main PID: 4997 (code=exited, status=0/SUCCESS)
CPU: 10ms

Jun 30 09:06:49 fog-svr.local systemd[1]: Starting nfs-server.service - NFS server and services…
Jun 30 09:06:50 fog-svr.local systemd[1]: Finished nfs-server.service - NFS server and services.

rpcinfo -p 192.168.13.99
192.168.13.99 mountd
rpcinfo -t 192.168.13.99 nfs
rpcin program vers proto port service
100000 4 tcp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100000 4 udp 111 portmapper
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 50174 status
100024 1 tcp 34667 status
100005 1 tcp 20048 mountd
100005 2 tcp 20048 mountd
100005 3 tcp 20048 mountd
100003 3 tcp 2049 nfs
100227 3 tcp 2049 nfs_acl
100021 1 udp 38178 nlockmgr
100021 3 udp 38178 nlockmgr
100021 4 udp 38178 nlockmgr
100021 1 tcp 37227 nlockmgr
100021 3 tcp 37227 nlockmgr
100021 4 tcp 37227 nlockmgr

I deployed the image using a VM on Proxmox and it worked, but with a phisical PC it gives the error like above. All are on the same VLAN.

@Tom-Elliott awesome, thank you!

Hello everyone,

I am facing an issue with image capturing after performing an upgrade on my FOG server from 1.5.10 to 1.5.10.1886. Before the update, everything worked fine for me. The images were stored directly on the Synology NAS.

My Setup:

FOG Server: IP 192.168.10.220 (Debian 13) Storage: External Synology NAS with multiple virtual IPs (192.168.109.220 and 192.168.110.220). Storage Configuration: The Synology NAS is configured in FOG web UI as the Master Node for its storage group. The local Default storage node is NOT the master. Clients: Multiple clients on different subnets (e.g., 192.168.109.23 and 192.168.110.23).

The Problem:
The Partclone phase finishes successfully on the client machine. The image files are correctly uploaded via NFS directly to the Synology NAS into the /images/dev/[MAC_ADDRESS] folder.

However, right after Partclone reaches 100%, the task gets stuck in the FOG Web UI (at around 70%), and the client screen shows the following PHP FTP error:

Error returned: Type: 2, File: /var/www/html/fog/lib/fog/fogftp.class.php, Line: 709, Message: ftp_put(/images/dev/[MAC]): Failed to open stream: No such file or directory, Host: 192.168.110.220, Username: foguser

What I have verified:

I tested the FTP connection manually via CMD/PowerShell from a PC using the same foguser credentials. I am able to log in, mkdir, rename, and rmdir inside the /images and /images/dev directories on the NAS without any permission errors. If I move and rename the MAC folder manually inside Synology File Station from /images/dev/[MAC] to /images/[Image_Name], the image works fine. This setup worked flawlessly before the FOG server upgrade. The /images directory is NOT mounted locally on the FOG server itself (and never had to be). Verified FTP username and password on NAS and FOG. It's same.

It seems that fogftp.class.php is incorrectly triggering ftp_put (trying to read a local file from the FOG server) instead of doing a remote ftp_rename directly on the NAS storage node.

Has anyone encountered this bug after a recent upgrade, or is there a specific setting in the new version that I missed?

Thank you for any help.

Storage Node for NAS
Storage Node for NAS.png

Error on PC
U10-PC13.jpg

@george1421

I’m interested in creating a working WiFi or USB network solution for device registration in FOG.

I have approximately 160 laptops to add to FOG that do not have a built-in Ethernet port. I’ve already tried using USB network adapters, but this has introduced extra complexity. In addition, a second laptop I tested is not consistently able to boot from the USB NIC, even though it worked on the first device.

To clarify, I am not attempting to image over WiFi. I only need network connectivity in the FOG environment so I can register each device and capture the correct MAC address. I will then image via Clonezilla using a USB-C NVME, which takes under three minutes to image each device

If possible, I would appreciate guidance on modifying the kernel so I can include future WiFi drivers.

I’ve attached the relevant information I believe you will need.
WhatsApp Image 2026-06-26 at 12.51.26.jpeg

@Tom-Elliott

Ah man that’s exactly what I needed. Thanks so much sir!

@JCS-RVK Understood and apologies there’s not a good method around this.

Thanks for at least understanding. I wonder if some of the similar types of issues we’ve seen historically have a similar style of problem that I’m only coming to realize now-a-days.

@Tom-Elliott

Just lyk that I updated the main FOG server to Debian 13 and installed the latest stable release of FOG.

Replication working well now that the OS and FOG server versions match the Storage Node server.

Thanks again

@Valer Hi Valer,

You can see my tutorial on using Secure boot with Shim, and my thoughts on what 2.0 means for Secure Boot with FOG here: http://forums.fogproject.org/post/158170

@Tom-Elliott

I’ve updated my FOG to the stable release and also updated my script with the following three lines, and everything’s fine – the database has been backed up successfully, it’s perfect!

fogApiToken="XYZ=" fogUsrToken="ZYF" curl -ik -X GET "http://$fogServerAddress/fog/system/export" -H "fog-api-token: $fogApiToken" -H "fog-user-token: $fogUsrToken" -o $backupDir/mysql/fog.sql 2>>$backupDir/logs/error.log 1>>$backupDir/logs/progress.log 2>&1

Thanks again for all your hard work on the FOG project!

Thanks @Tom-Elliott !

Perhaps we could include a brief note stating that it is possible the database schema may not need updating.

@Tom-Elliott said in Unauthorized error:

@Jamaal I’m not sure I follow? The database isn’t insecure, it was being able to download the database, or force an upgrade without authorization that was the piece being secured, nothing about the normal day to day operation of the database changed.

Got it, ok thanks for your help today on this.

Shoutout “The Minester”

https://github.com/FOGProject/fogproject/issues/685

On the storage node, create a .my.cnf file in root’s home directory:

sudo tee /root/.my.cnf << ‘EOF’
[client]
skip-ssl = true
EOF

MariaDB will try to connect with SSL by default but that’s not enabled on the main FOG server. This is why I had to use the --ssl=FALSE flag when I connected to mysql manually.

The installation succeeded!

@Nono Edit your /opt/fog/.fogsettings file and replace entries of ‘mysql-client’ with ‘mariadb-client’

I suspect they’ve updated the repo to solely exist for mariadb-client, but you had it before that package switch/change occurred so your fogsettings file is just expecting mysql-client always.

I might also recommend removing the existing mysql-client package just to ensure clean flow, though of course get a backup before any such actions.

Works well ! 😊