FTP Login goes to FOG User Home Dir instead of dir in WebUI

[lovejw2]

FTP Login goes to FOG User Home Dir instead of dir in WebUI

[Wayne Workman]

@lovejw2 We need more details. Please answer these:

• What version of FOG?
• What OS & version?
• What’s the context?
• What’s broken?

[lovejw2]

@Wayne-Workman
FOG Version: 1.5.4
OS: Debian 9

When I connect to the server via FTP the folder it connects to is the FOG user home dir and not the /images directory that is set in the FOG WebUI

I had to reinstall Debian due to the VM having massive errors on the main drive. I left the images on the separate drive that they were on and due to losing the database I lost the profiles for the images. I recreated the Profiles and pointing them to the directories where they are.

[lovejw2]

Also getting this error when I try to deploy an image!

[Wayne Workman]

@lovejw2 said in FTP Login goes to FOG User Home Dir instead of dir in WebUI:

When I connect to the server via FTP the folder it connects to is the FOG user home dir and not the /images directory that is set in the FOG WebUI

I think that is normal behavior. Also, an FTP issue (which I don’t think you have) would not prevent an image deployment from being successful.

When you say massive errors on the main drive, what do you mean? Was the disk corrupted? Where did this image that failed to deploy come from? That bad disk? Also, the image definition you create in the web GUI must be exactly the same for certain fields otherwise the image will fail to deploy.
See these for more details:

• https://wiki.fogproject.org/wiki/index.php?title=Migrate_images_manually
• https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG

Do you have a good backup of your old fog server, or a good backup of the images, or a good backup of the database? We can help you with restoring those.

[Tom Elliott]

@lovejw2 Based on the message you’re seeing for this particular image, when was this imaged captured? What’s the compression manager set to? The message that appears is that parclone isn’t even running (cat: /tmp/partclone.log: No such file or directory). This can happen for a few reasons, for example if you have the image manager set to partimage, when it should be partclone. Because partclone doesn’t run, the partclone.log file would not be created. My guess, for most people. is your image was captured using partclone gzip at compression rating 6. The compression rating itself doesn’t mean anything for deploy, it’s when it’s captured this plays the large part.

Hopefully this helps.

[lovejw2]

@wayne-workman
My fog server is a virtual machine and the root drive got corrupted. The /images were on a different virtual drive. I forgot to make sure it was added to my Veeam backup.

The FTP part i just wasn’t sure of. One of my techs informed me of the other issue after i posted on here.

Our images were captured with all the default settings

[lovejw2]

@tom-elliott
Yes, I found the issue was that I had picked the wrong option on the new Profile. It was set to PartImage instead of Partclone. Changed that option and it deployed properly.