@gabbas said in Snapin not working as a Batch file xcopy:

everyone has read and execute permission to this folder

Is it really everyone as in anonymous without authentication or is it all users/group members of your organization? I ask because the FOG client is running as service and won’t have the same auth tokens as if you run the script as user.

Hi,
I tried the password fix and it didn’t help.
Did you manage to overcome this issue?

The Fog Client and Fog Server are up to date and database is fixed.

Now the Fog Server working properly now.

Thank You for your help.

@Cire3 Hey I’m glad you have it worked out. You found one of the gotchas with naming (No special characters as the first character in the names).

@Wayne-Workman thanks i was able to figure it out, and yes im an old fog user and installer. I had to changed the fogstorage mysqlpassword on my storage node on the .fogsettings (/opt/fog/.fogsettings) Once i changed it to the one provided by the Fog Server everything worked.

@matijn Don’t edit core files for this. (they’ll be overwritten at next update)

Instead update your /opt/fog/.fogsettings file with the credentials and rerun the fog install script.

Ok.
It seems i decided to enter no root password for mysql while running the installation, after I tried to configure a less secure root password.

After setting a very very strong password on mysql root account (phpmyadmin).
You have to manually edit:

sudo nano /var/www/fog/lib/fog/Config.class.php

In my case, for Ubuntu 18.04.1 LTS
sudo nano /var/www/html/fog/lib/fog/Config.class.php

private static function _dbSettings()
enter credentials.

@Sebastian-Roth & @george1421
Thank you for your help. Updated the kernel and inits the way you described it. Now the capture works.
Installed 1.5.4 on august 9th, as far as I can see.

@kratkale Read through this topic, possibly you have many client’s talking to the FOG server (and the DB for that reason) which might cap the connections.

About the printers, I might ask you to open new topics so we don’t loose track of different issues in one thread.

@ablohowiak Maybe play with the image settings (e.g. Image Type and Image Manager) might make those images work again. As we don’t know your settings it’s just a wild guess. But if the images worked on your 1.4.4 server they should work on 1.5.4 just as well if you get the image settings right.

@george1421 It worked the policy was disable on each scope and the secure boot on enable, just had to activate the policy and and disable secure boot

@mxc In the second video I don’t see the client PXE booting at all?!? Maybe I get you wrong?

In the first video it looks like a legacy BIOS PXE boot (not UEFI). Try different boot exit style settings for BIOS (and maybe UEFI just in case)…

Please resolved this post. we went virtual machine route to capture image and it worked.

Thank you for support.

@Wayne-Workman the 6 first of the mac are the same and fog could see somes of theese MAC.

i’m still looking for BUT you’re right @Sebastian-Roth , the forticlient have an integrated FW, maybe the problem… today i will look if I can turn off the FW part and you say after

@afaure Please provide more information. On the FOG server run the following commands and post the full output here: df -h, lsblk, showmount -s

@Cire3 said in Can't see Images in menu after manually uploading.:

The compression scale also must match huh ?

Sorry, I didn’t mean the compression scale but the compression format…

Thanks for all the help! things seem to be back in order!

In fact, i must be wrong.
What is the “*” at the end of the name of the server in the “storage node disk usage”.
It is the Master Node or the current server ?

@Sebastian-Roth I think I found it - I had to add the snapin to the group!