Deploy Problem (Unable to locate image store)
-
[SIZE=16px][COLOR=#212121][FONT=inherit]I have twice the image uploaded to the fog but every time is that the image size is 0.00GB small.[/FONT][/COLOR][/SIZE]
Look the screenshot please
what i can do `?
[url=“/_imported_xf_attachments/1/1481_Unbenannt.jpg?:”]Unbenannt.jpg[/url][url=“/_imported_xf_attachments/1/1483_11.png?:”]11.png[/url][url=“/_imported_xf_attachments/1/1482_111.png?:”]111.png[/url]
-
Permissions bro !!! The folders you have there “0023…” and “0026…” are in fact your images … the problem is that the system uploaded the images BUT did not rename the folder. Those two numbers are in fact the mac addresses of your two computers that you grabbed the images from. Can you make sure that your /images directory itself has the correct permissions ?
Now a question for the fog developers: those two folders have +777 permissions … which means world readable/writable - why is that fog is unable to rename those folders? My folders on my fog server are also +777 permissions.
-
[quote=“axel12, post: 38696, member: 24592”]Permissions bro !!! The folders you have there “0023…” and “0026…” are in fact your images … the problem is that the system uploaded the images BUT did not rename the folder. Those two numbers are in fact the mac addresses of your two computers that you grabbed the images from. Can you make sure that your /images directory itself has the correct permissions ?
Now a question for the fog developers: those two folders have +777 permissions … which means world readable/writable - why is that fog is unable to rename those folders? My folders on my fog server are also +777 permissions.[/quote]
The /images folder is set to 777 permissions yes. Any local user could potentially login, move, and rename the folders, Yes. But this is not how fog works.
FOG Mounts the /images and /images/dev folders at image time. For upload tasks, /images/dev is nfs mounted with read-write permissions. For download tasks, /images is nfs mounted with read-only tasks. Why?
The intention of using NFS is a quick and simple means to handle dealing with large file sets. Why the change between read-only and read-write? I think this boils down to simple security methods. By only allowing read-only to the /images nfs mount, we have ensured safety of overwriting images especially in the case of debug tasks from the client.
Our approach to moving the /images/dev/<macaddress> is to FTP the data after it’s completed uploading. This FTP has read/write world wide as the FTP user must also be a local user on the system you’re trying to copy the image to. This is most likely where waldiadmin’s issue is. The fog user and password is not correct, which would also explain the size not appearing correctly for the image. One, the image doesn’t exist where it’s supposed to, two , the username and password are not correct.
-
… then at which point does /images/dev/<mac> go away and move into /images? should be after the upload is finished … ?
-
Correct,
But if there’s a problem, usually it won’t try to continue on as it can’t complete the job. However, I’ve heard of similar problems in the past. I’ve never experienced it myself, and don’t know why it’s not operating as expected.
Specifically, it calls the service/Post_Stage2.php file for uploads, so maybe there’s some issue that I’ve just not seen quite yet?
-
[SIZE=16px][COLOR=#212121][FONT=inherit]Now that I have a new FOG 1.2.0 placed under Ubuntu 04.14.01 and have uploaded an image comes , see LOG this error . The client is now output as error message "Unable to locate image store and no Windows 7.8 image "[/FONT][/COLOR][/SIZE]
[COLOR=#212121][SIZE=16px][FONT=inherit]how can I fix this trouble, instructions ? because my skills are not so good . I only work on the terminal[/FONT][/SIZE][/COLOR]
[url=“/_imported_xf_attachments/1/1486_Unbenannt.png?:”]Unbenannt.png[/url][url=“/_imported_xf_attachments/1/1487_Unbenannt2.png?:”]Unbenannt2.png[/url][url=“/_imported_xf_attachments/1/1488_Unbenannt1.png?:”]Unbenannt1.png[/url][url=“/_imported_xf_attachments/1/1489_Unbenannt3.png?:”]Unbenannt3.png[/url][url=“/_imported_xf_attachments/1/1490_Unbenannt4.PNG?:”]Unbenannt4.PNG[/url]
-
Can you send a screen of your /images (ls -lah /images)
and also, how many storage groups do you have … -
yes of course! Thanks for your Help:)
We have “multiple Partition Image -Single Disk (Not Resizable)- (2)”
[url=“/_imported_xf_attachments/1/1494_ls-lah images.PNG?:”]ls-lah images.PNG[/url]
-
I experienced a similar problem. I manually moved the folder for my image from images/dev and renamed it. That enabled me to use it. How can I ensure that I don’t need to do this for future images. I had changed the default password for the fog user. Should I change it back or is there another place that I should change it?
Fog 1.2.0
Ubuntu 14.04 TLS -
Are you sure access rights and FTP login data are set correctly? See Storage Managment -> Management Password and Unix fog user password. Those two need to match!!! Try it out:
[CODE]ftp 127.0.0.1
Connected to 127.0.0.1.
220 (vsFTPd 2.3.5)
Name (127.0.0.1:username): fog
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>[/CODE]If login failes with the password you saw in the web gui you can set the unix password to match again:
[CODE]sudo passwd fog
…[/CODE]In case file rights (chmod 777 …) and FTP login data all seem to be fine then you might experience the same problem that I see on our machines which are running on openvz (proxmox). See my post here: [url]http://fogproject.org/forum/threads/failed-to-create-deployment-tasking.12427/#post-44443[/url]
-
You must also be sure that FTP is actually running on the FOG server.
[CODE]sudo service vsftpd restart[/CODE]
If it’s not configured right, it should give some errors which will help.
This could also be firewall related, potentially.
