Reclaim Used Disk Space on FOG Server?

I’ve been having some issues deleting images and reclaiming used disk space when attempting to remove unneeded system images. Using the option to remove the image definition and data doesn’t result in the image being removed, but selecting the image from “List All Images”, checking the image in question and selecting it for deletion appears to remove the image definition but not the data. When I review the amount of disk space used, it remains unchanged. Is there a “disk cleanup” option to reclaim disk space that I’m overlooking? Any help would be greatly appreciated.

Using the option to remove the image definition and data doesn’t result in the image being removed

Deleting definitions directly from the “list all” listing does not delete image data. That’s by design. The developers didn’t want it to be so easy to obliterate every image, and I agree with their choice. However, @Developers there probably should be some sort of message displayed when this method is used saying “hey, the data won’t be deleted if you do it this way.”

The below are simplified instructions for FOG 1.3.x, for the Linux newbie on how to do it right, and how to clean up the mess. Not calling you a noob, but I write for future readers too, not just you.

How to quickly delete definitions but not data:Web Interface -> Image Management -> List All Images -> Click the checkboxes to the left of the image definitions -> Click "Delete All Selected Images?" at bottom of page -> Click "Are you sure you wish to delete these items?" -> Authenticate to confirm

How to delete a single image definition and it’s data too:Web Interface -> Image Management -> List All Images -> Click the name of the image you want to delete -> Click "Delete" from the left menu -> Check the box labled "Delete file data" -> Click "Remove" -> Authenticate to confirm

How to clean up the stuff you didn’t delete the data for:
On your FOG Server via Terminal or SSH, become root properly with:sudo -i
Access the database via CLI with:mysql -D fog or if it’s password protected: mysql -D fog -u root -p
Get a listing of the legitimate image paths (not the same as image names):select imagePath from images;
Exit mysql once you have the list:quit

These paths do not have the image path directory with them. The default image path is /images on your server. If you inherited the server, it may not be the default. You can check what it is with this query (in the fog database):select ngmRootPath from nfsGroupMembers;
Or by looking in the web interface here:Web Interface -> Storage Mangement -> [click node name] -> Image Path

Now, once you have the Image Path, you can do something like this:ls -l /images or whatever the image path is.
Compare this list to the output from the database.

The dev directory or any file named .mntcheck these are required for FOG to operate.

Say you have an image that showed up in the ls output, but not in the database output. Say that image was called Acerbase. First, all things in Linux are case sensitive - you mistype a case and this doesn’t work, or does something you don’t want to happen.

Here’s how to delete that image:rm -rf /images/Acerbase

After getting this done, you might look inside of the dev directory to see if there are any partial images from failed uploads.ls -l /images/dev
Again, do not delete any file named .mntcheck but it’s safe to delete everything else in here, but just not the dev directory itself.