prestodb/presto · error · PrestoException

ICEBERG_FILESYSTEM_ERROR

ICEBERG_FILESYSTEM_ERROR

Error message

Failed to delete file: ${path}

What it means

HdfsFileIO.deleteFile deletes a file (non-recursive) through Hadoop's FileSystem within the configured HdfsEnvironment doAs block. On IOException the operation is wrapped in a PrestoException with code ICEBERG_FILESYSTEM_ERROR, meaning the underlying filesystem refused or failed the delete.

Source

Thrown at presto-iceberg/src/main/java/com/facebook/presto/iceberg/HdfsFileIO.java:85

                new HdfsCachedInputFile(inputFile, new ManifestFileCacheKey(manifest.path()), manifestFileCache) :
                inputFile;
    }

    @Override
    public OutputFile newOutputFile(String path)
    {
        return new HdfsOutputFile(new Path(path), environment, context);
    }

    @Override
    public void deleteFile(String pathString)
    {
        Path path = new Path(pathString);
        try {
            environment.doAs(context.getIdentity().getUser(), () -> environment.getFileSystem(context, path).delete(path, false));
        }
        catch (IOException e) {
            throw new PrestoException(ICEBERG_FILESYSTEM_ERROR, "Failed to delete file: " + path, e);
        }
    }

    protected InputFile newCachedInputFile(String path)
    {
        InputFile inputFile = new HdfsInputFile(new Path(path), environment, context);
        return manifestFileCache.isEnabled() ?
                new HdfsCachedInputFile(inputFile, new ManifestFileCacheKey(path), manifestFileCache) :
                inputFile;
    }
}

View on GitHub (pinned to 55bb57d202)

Solutions

1. Check that the Presto service user (or impersonated user) has delete permission on the path; fix HDFS ACLs or object-store IAM policy.
2. Confirm the file still exists and is not locked/being deleted concurrently; retry after the competing job finishes.
3. Validate HdfsEnvironment/impersonation configuration (fs permissions, doAs settings).
4. Fix connectivity to the Namenode/object store (DNS, network) indicated in the wrapped IOException cause.

Example fix

// before
io.deleteFile(pathString);
// after: guard with existence + retry
FileSystem fs = environment.getFileSystem(context, new Path(pathString));
if (fs.exists(new Path(pathString))) { io.deleteFile(pathString); }

Path p = new Path(pathString);
FileSystem fs = environment.getFileSystem(context, p);
if (!fs.exists(p)) return; // nothing to delete
fs.access check / hdfs dfs -test -w path

boolean canDelete(HdfsContext ctx, String path) { try { return environment.getFileSystem(ctx, new Path(path)).exists(new Path(path)); } catch (IOException e) { return false; } }

try { fileIo.deleteFile(path); } catch (PrestoException e) { if (e.getErrorCode().getName().contains("FILESYSTEM_ERROR")) { log.warn("delete failed: " + path, e); /* retry or mark for cleanup */ } else throw e; }

When it happens

Trigger: Deleting a data/metadata file (e.g. Iceberg cleanup, delete orphans) when the HDFS/object-store delete call throws IOException: permission denied for the delegated user, file already gone with no idempotency, unknown host/Namenode errors, or object-store failures (S3 403/404 mapped to IOException).

Common situations: Wrong HDFS permissions/impersonation config, files deleted concurrently by another job, S3 credentials lacking delete permission, network partition to Namenode or object store.

Related errors

• HIVE_FILESYSTEM_ERROR
• ICEBERG_FILESYSTEM_ERROR
• ICEBERG_FILESYSTEM_ERROR
• HIVE_FILESYSTEM_ERROR
• HIVE_FILESYSTEM_ERROR

AI-assisted analysis of prestodb/presto@55bb57d202 (2026-09-04). Data as JSON: /api/errors/71d61b3cc0c23c62. Report an issue: GitHub.