That’d work too I suppose.

An image defined as “All disks” will upload from all disks and deploy to all disks… So, yes. You need to (re-)upload.

Any errors in apache log file?

@the_duke then I doubt the DB backup worked correctly, or, I doubt the import went correctly.

I would ask that you try the suggested fixes in this thread, and report back on their results.

Either a FTP issue as Junkhacker already said or possibly an ext3 filesystem issue (which is a bit unlikely in your case using ubuntu). If all FTP tests on your machine are working great then you might want send us the output of sudo mount

You may be right. For me collecting informations about image creating statistics, doing automation about storage spaces can be done after new images came alive. I can manage it elsewhere, just was wondering if post-upload scripting is possible somehow 🙂

Thanks Tom, it’s version1.20

@Fritch94 details as in what have you tried? What version of fog? Did you try the information in this thread.

@Tom-Elliott said:

change the /etc/apt/sources.list file
Edit the file so all the us.archive and security links are updated to old-releases.

An example?

The OS is Centos 6.7. But I think what was changed works across the linux distros. The wgetrc thing is specific to wget and I know I’ve made that change on FreeBSD as well as various flavors of linux. The environment settings should also be universal.

@Tom-Elliott Working with latest update TY

I can also confirm that version 4866 resolved the issue.

After the SVN update, there is now a new option for placing a plain-text password that will auto-encrypt. The problem was, my encrypted password before the update was placed in the new plain-text field. I just repopulated a new encrypted PW, placed it in the legacy field and that did the trick.

Cheers!
Tim

@giolnl said:

I made some tests with a “forced” configuration (meaning I actually bypassed the GUI of OMV) and everything worked

Not forced, simply a manual configuration. 🙂

The OS doesn’t care what the GUI says. The OS is going to read the /etc/exports file for exports, that’s how it works. 🙂

@Junkhacker I had multiple hard drives I was trying to image at once and once this issue started popping up I actually did switch to re sizable but it was still having that issue strangely.

IMHO this was not related to permissions as you see that pretty much all files and directories already had 777 mask.

Please help us with some more information about your system. FOG version, disk layout, operating system(s) on the client, image type (resizeable?)

This command might help you finding out what kernels you have:

$ file /var/www/fog/service/ipxe/bzImage* /var/www/fog/service/ipxe/bzImage: Linux kernel x86 boot executable bzImage, version 3.15.6 (root@debian64) #1 SMP PREEMPT Fri Jul 18 23:58:44 EDT 2, RO-rootFS, swap_dev 0x5, Normal VGA /var/www/fog/service/ipxe/bzImage32: Linux kernel x86 boot executable bzImage, version 3.15.6 (root@debian64) #1 SMP PREEMPT Fri Jul 18 23:58:56 EDT 2, RO-rootFS, swap_dev 0x5, Normal VGA

This output is on a 1.2.0 test install on my laptop. So I guess 1.2.0 came with 3.15.6