Download task failed to create
-
images aren’t supposed to stay in the /images/dev/<mac address> location
after an image is finished being uploaded, it is supposed to moved to /images/<image name>
images are uploaded over NFS and moved afterward with FTP. it sounds like the FTP part failed on your upload -
[quote=“ch3i, post: 39522, member: 2513”]Hi,
Your image must be in the /images/P8BMWES7 folder not in /images/dev/10bf484ca18f. The last is a temporary folder for the upload task.
Regards,
Ch3i.[/quote]Okay, I created that /images/P8BMWES7 directory manually, and copied the image files into it. Then I updated the image entry in the Fog web UI with the new path, and tried to set up the download again. Same result I’m afraid.
-
[quote=“Junkhacker, post: 39523, member: 21583”]images aren’t supposed to stay in the /images/dev/<mac address> location
after an image is finished being uploaded, it is supposed to moved to /images/<image name>
images are uploaded over NFS and moved afterward with FTP. it sounds like the FTP part failed on your upload[/quote]Any idea why this FTP part might have failed, or suggestions for how I might diagnose the problem?
-
in the storage management section, there’s a management username (default of “fog”) and password stored. see if you can use those credentials to log into the server with an FTP client
-
[quote=“Junkhacker, post: 39526, member: 21583”]in the storage management section, there’s a management username (default of “fog”) and password stored. see if you can use those credentials to log into the server with an FTP client[/quote]
It appears that there was no password set at first. I tried ftp to the server with a blank password, but that didn’t work. So I set the password to “password” (same as for the TFTP config) using the web UI, and tried again. Same result. I also tried it from the console on the server itself in case there was a firewall problem, but it didn’t help.
There are two “vsftpd” processes running on the server. Would those be the ones Fog is using?
-
[quote=“Peter Dickinson, post: 39524, member: 27370”]Okay, I created that /images/P8BMWES7 directory manually, and copied the image files into it. Then I updated the image entry in the Fog web UI with the new path, and tried to set up the download again. Same result I’m afraid.[/quote]
Could you post a screenshot of your image page and host page ?
-
[quote=“ch3i, post: 39531, member: 2513”]Could you post a screenshot of your image page and host page ?[/quote]
Well, I tried. I seem to have a new problem now. As you can see from the screenshot of the image management page, the “password” password that I set in the storage management config seems to have broken this. And it won’t allow me to reset the password to blank as it was before![ATTACH=full]1529[/ATTACH][ATTACH=full]1530[/ATTACH]
[url=“/_imported_xf_attachments/1/1529_FOG host.JPG?:”]FOG host.JPG[/url][url=“/_imported_xf_attachments/1/1530_FOG images.JPG?:”]FOG images.JPG[/url]
-
Hi,
You can try this : [url]http://fogproject.org/forum/threads/fog-ftp-login-failed.11787/#post-37394[/url]
Regards,
Ch3i. -
Thanks, that seems to have worked. I reset the password in Storage Management to my user’s login password on the FOG server, and now I can look at the FOG images. I’ve attached the other screenshot you requested. I also tried FTP into the FOG server using this same password, and that works too
The FOG installation uses a number of different user/password combinations for different things, and it wasn’t clear to me which was needed for FTP.So that leaves the questions of why the renaming of the temporary directory /images/dev/(MAC address) to /images/P8BMWES7 didn’t happen automatically? And why when I made this change manually FOG still won’t download the image, but displays the red error box?
[ATTACH=full]1531[/ATTACH]
[url=“/_imported_xf_attachments/1/1531_FOG image.JPG?:”]FOG image.JPG[/url]
-
[quote=“Peter Dickinson, post: 39563, member: 27370”]
So that leaves the questions of why the renaming of the temporary directory /images/dev/(MAC address) to /images/P8BMWES7 didn’t happen automatically? And why when I made this change manually FOG still won’t download the image, but displays the red error box?
[/quote]Actually I have the same problem during renaming /dev/mac_adress to /images/image_name… But no problem to download the image after manually move files into /image/image_name.
I don’t understand why you have the error when you try to download it… sorry.
Are you sure that your rights are proper on the /images folder ? -
No, I’m not sure really. I’ve attached a screenshot from a terminal to the server. I set the permissions and ownership according to another post about FOG that I had found previously when I was investigating why the imaging wasn’t working. It basically suggested setting the ownsership to root and the permissions to 777 for /images and everything in it. /images/P8BMWES7 has different permissions and ownership because it was created manually later.
One detail that may be relevant here is that /images is actualy located on a different drive than the rest of the filesystem. It is located on /dev/sdb1 whereas everything else is on /dev/sda1. That’s because I created a seperate virtual disk for the /images directory so that the images could be backed up and copied around more easily. One consequence of that is that the /images directory was not created by the FOG installation script. It was created when the Ubuntu installation was done. So the permissions and ownership may well be different.
[ATTACH=full]1532[/ATTACH]
[url=“/_imported_xf_attachments/1/1532_FOG permissions.JPG?:”]FOG permissions.JPG[/url]
-
Make sure all permissions are set correctly:
[code]chmod 777 -R /images[/code]
-
Only reason I can think Upload isn’t moving the files is because the Move uses FTP to perform the action from /images/dev/<mac-address> to /images/<imagename>. If, during the time the image was completed, the FTP information on the storage node (User and Password) were not correct, this would explain why it didn’t copy it over.
-
I reset the permissions of /images and everything under it to 777 (again), and also set the owner and group to root. This seems to have fixed the problem. Not sure why it didn’t work with the first couple of images I created, but it seems to be working now. Thanks for your help everyone
