What causes "editor::lang.filesystem.error_deleting_file" in octobercms/october?

Grant the PHP user write on the directory that holds the file: chown/chmod the parent dir (e.g. chmod u+w themes/demo/assets/css)

octobercms/october · error · ApplicationException

editor::lang.filesystem.error_deleting_file

Error message

editor::lang.filesystem.error_deleting_file

What it means

Thrown by editorDeleteFileOrDirectory when File::delete() (error-suppressed) returns false for a regular file (lines 129-136). Message interpolates the path: 'Error deleting file :name.'. unlink() failing at this point almost always means the PHP user cannot write the containing directory (deleting a file modifies the directory entry), or the file is locked/immutable.

Source

Thrown at modules/editor/traits/FileSystemFunctions.php:132

     * editorDeleteFileOrDirectory
     */
    protected function editorDeleteFileOrDirectory($basePath, $fileList)
    {
        // Delete leaves first
        usort($fileList, function($a, $b) {
            return strlen($b) - strlen($a);
        });

        foreach ($fileList as $path) {
            if (!$this->validateFileSystemPath($path)) {
                throw new ApplicationException(Lang::get('editor::lang.filesystem.invalid_path'));
            }

            $fullPath = $basePath.'/'.$path;
            if (File::exists($fullPath)) {
                if (!File::isDirectory($fullPath)) {
                    if (!@File::delete($fullPath)) {
                        throw new ApplicationException(Lang::get(
                            'editor::lang.filesystem.error_deleting_file',
                            ['name' => $path]
                        ));
                    }
                }
                else {
                    $empty = File::isDirectoryEmpty($fullPath);
                    if (!$empty) {
                        throw new ApplicationException(Lang::get(
                            'editor::lang.filesystem.error_deleting_dir_not_empty',
                            ['name' => $path]
                        ));
                    }

                    if (!@rmdir($fullPath)) {
                        throw new ApplicationException(Lang::get(
                            'editor::lang.filesystem.error_deleting_dir',
                            ['name' => $path]

View on GitHub (pinned to b608633a7e)

Solutions

Grant the PHP user write on the directory that holds the file: chown/chmod the parent dir (e.g. chmod u+w themes/demo/assets/css)
Check locks: lsof +D themes/<theme>/assets on Linux, or close the editor/IDE holding it on Windows
Clear the immutable flag if set: lsattr <file> then chattr -i <file>
Verify the volume is mounted read-write for the webserver user

Example fix

# before: dir not writable by webserver -> unlink fails
$ sudo lsattr themes/demo/assets/css/app.css  # shows 'i'
# after
$ sudo chattr -i themes/demo/assets/css/app.css
$ sudo chown www-data: themes/demo/assets/css

Defensive patterns

Strategy: try-catch

Validate before calling

$full = $assetsBase.'/'.$path;
if (file_exists($full) && !is_writable(dirname($full))) {
    // deletion modifies the DIRECTORY entry — fix dir perms first
}

Try / catch

try {
    if (!@File::delete($fullPath)) {
        throw new ApplicationException(Lang::get('editor::lang.filesystem.error_deleting_file', ['name' => $path]));
    }
} catch (ApplicationException $e) {
    Log::warning('asset delete failed', ['path' => $path, 'user' => get_current_user()]);
    throw $e; // surface to the AJAX client, or queue for manual cleanup
}

Prevention

Ensure every assets subdirectory is writable by the PHP user (delete needs dir write, not file write)
Run deploys as the same user as php-fpm/www-data, or chown afterwards
Watch for the immutable flag ('i') on hardened servers before blaming the code

When it happens

Trigger: command_onAssetDelete on files under themes/<theme>/assets when the directory is owned by root or another user; a file held open by another process on Windows; the 'i' immutable flag set by a deploy hardening step; read-only mount.

Common situations: CI/CD or dockerized setups that build themes as root while php-fpm runs as www-data; hardened servers with immutable web assets; NFS/SMB mounts without write perms for the webserver user.

Related errors

AI-assisted analysis of octobercms/october@b608633a7e (2026-08-21). Data as JSON: /api/errors/d8b9f40b05f1e2c3. Report an issue: GitHub.