# Troubleshooting "It Was Not Possible to Delete One or More Files" in OpenMage Image Cleaner

> Troubleshoot OpenMage Image Cleaner's 'It was not possible to delete one or more files' error. Learn common causes like permission issues, file locks, or path errors.

- Repository: [Fabrizio Balliano/openmage-image-cleaner](https://github.com/fballiano/openmage-image-cleaner)
- Tags: troubleshooting
- Published: 2026-03-01

---

**The "It was not possible to delete one or more files" error appears in OpenMage Image Cleaner whenever a filesystem `unlink()` or directory removal operation fails, typically due to permission issues, file locks, or incorrect path resolution.**

The `fballiano/openmage-image-cleaner` module identifies and removes orphaned images from your OpenMage (Magento 1) installation. When the system displays this message, it indicates that the controller's attempt to purge files was rejected by the operating system, leaving database records intact while the physical files remain on disk.

## Where the Error Originates in the Source Code

The error message is hardcoded in [`app/code/community/Fballiano/ImageCleaner/controllers/Adminhtml/FbimagecleanerController.php`](https://github.com/fballiano/openmage-image-cleaner/blob/main/app/code/community/Fballiano/ImageCleaner/controllers/Adminhtml/FbimagecleanerController.php) and triggered whenever a deletion routine returns **false**. The controller emits the warning from five specific contexts.

### Single Image Deletion (`deleteAction`)

At **line 240**, the controller calls `unlink($image_path)` on the selected file. If this function returns **false**, the module adds the error message to the admin session and skips the database deletion.

### Mass Deletion (`massDeleteAction`)

At **line 269**, the controller iterates over multiple image IDs. If any `unlink()` call fails, the error message is added once (guarded by `$error_message_thrown`) to prevent duplicate notifications, but the loop continues processing remaining items.

### Folder Flush Operations

The error also appears when flushing temporary directories:

- **media/tmp** (line 288)
- **media/import** (line 306)
- **var/export** (line 324)
- **var/importexport** (line 342)

In these cases, `Varien_Io_File::rmdirRecursive()` attempts to empty the folder. If `$helper->scandirRecursive()` detects leftover files afterward, the error is displayed.

## Root Causes of the Deletion Failure

When OpenMage Image Cleaner reports that it cannot delete files, the underlying issue usually falls into one of these categories:

- **Insufficient filesystem permissions** – The web server user (e.g., `www-data`, `apache`) lacks write access to the target file or parent directory.
- **File locks or active processes** – The image is currently being handled by another PHP process, FTP transfer, or system backup, preventing removal.
- **Path resolution errors** – The calculated `$image_path` points to a non-existent location or a broken symlink, causing `unlink()` to fail.
- **Security restrictions** – SELinux, AppArmor, or read-only mount flags block write operations on the `media/` or `var/` directories.

## Code Implementation Details

Understanding the exact implementation helps diagnose which specific check is failing.

### Single File Deletion Logic

```php
// From FbimagecleanerController.php around line 240
$image_path = $helper->getMediaDirByEntityTypeId($image['entity_type_id']) . $image['path'];
if (unlink($image_path)) {
    // success – DB row removed
    $db->query("DELETE FROM {$cleaner_table} WHERE image_id=?", $image_id);
} else {
    // failure – admin sees the error message
    Mage::getSingleton('adminhtml/session')
        ->addError($this->__('It was not possible to delete one or more files from the filesystem.'));
}

```

### Mass Delete Loop

```php
// From FbimagecleanerController.php around line 269
foreach ($ids as $image_id) {
    $image = $db->fetchRow("SELECT * FROM {$cleaner_table} WHERE image_id=?", $image_id);
    $image_path = $helper->getMediaDirByEntityTypeId($image['entity_type_id']) . $image['path'];
    if (!unlink($image_path)) {
        // First failure sets the generic error message once
        if (!$error_message_thrown) {
            $error_message_thrown = true;
            Mage::getSingleton('adminhtml/session')
                ->addError($this->__('It was not possible to delete one or more files from the filesystem.'));
        }
        continue;
    }
    $db->query("DELETE FROM {$cleaner_table} WHERE image_id=?", $image_id);
}

```

### Temporary Folder Flush Check

```php
// From FbimagecleanerController.php around line 288 (media/tmp example)
$media_dir = Mage::getBaseDir('media') . '/tmp';
Varien_Io_File::rmdirRecursive($media_dir, true);
@mkdir($media_dir);

$leftover = $helper->scandirRecursive($media_dir);
if ($leftover) {
    Mage::getSingleton('adminhtml/session')
        ->addError($this->__('It was not possible to delete one or more files from the media/tmp folder.'));
} else {
    Mage::getSingleton('adminhtml/session')
        ->addSuccess($this->__('media/tmp was successfully flushed'));
}

```

## How to Resolve the Error

Follow these diagnostic steps to clear the warning and successfully purge images:

1. **Verify ownership and permissions** – Ensure the web server user owns the `media/` and `var/` directories and has write permissions (typically `755` or `775` with proper group ownership).
2. **Check for immutable flags** – On Linux systems, run `lsattr` to verify that files haven't been marked immutable (`+i` attribute).
3. **Review SELinux/AppArmor logs** – Check `/var/log/audit/audit.log` for AVC denials that indicate security policy blocks.
4. **Confirm path integrity** – Manually verify that the paths constructed by `getMediaDirByEntityTypeId()` resolve to actual files and not broken symlinks.
5. **Clear locks** – If using NFS or clustered storage, ensure no stale file locks exist from other nodes.

## Summary

- The "It was not possible to delete one or more files" error signals a failed `unlink()` or `rmdirRecursive()` operation in [`FbimagecleanerController.php`](https://github.com/fballiano/openmage-image-cleaner/blob/main/FbimagecleanerController.php).
- The message appears at lines 240, 269, 288, 306, 324, and 342 depending on whether you are deleting single images, mass-deleting, or flushing temporary folders.
- Failed deletions leave database rows intact, meaning the images remain listed as "unused" in the admin grid until the underlying filesystem issue is resolved.
- Root causes almost always involve permission mismatches, active file locks, or security module interference.

## Frequently Asked Questions

### Why does the image still appear in the Image Cleaner grid after the error?

The database record in `fb_imagecleaner_image` is only removed after a successful `unlink()` call. When deletion fails, the controller skips the SQL `DELETE` statement to prevent orphaned files without records, so the image remains visible until you fix the permissions and retry.

### Can I delete the files manually via SSH or FTP to bypass the error?

Yes. If you manually remove the files from `media/catalog/product/` or the relevant temporary folders, you can then use the "Sync" function in the Image Cleaner to refresh the grid. The module will detect that the physical files are gone and remove the database entries accordingly.

### Does the mass delete operation stop when it hits the first failure?

No. The loop in `massDeleteAction` uses a `continue` statement after logging the error, meaning it attempts to delete every selected image even if previous ones failed. The error message is only displayed once per request to avoid flooding the admin session.

### How can I identify which specific file caused the deletion failure?

The current implementation in `fballiano/openmage-image-cleaner` does not log the specific `$image_path` that failed. To identify the culprit, temporarily modify [`FbimagecleanerController.php`](https://github.com/fballiano/openmage-image-cleaner/blob/main/FbimagecleanerController.php) to add `Mage::log($image_path)` inside the `else` block of the `unlink()` check, or check your web server error logs for permission denied messages that correlate with the timestamp of the admin action.