What causes "Failed to delete path: {}" in apache/iceberg?

Verify the path exists and the account key/OAuth identity has Storage Blob Data Contributor (delete) rights

Failed to delete path: {}

Error message

Failed to delete path: {}

What it means

ADLSFileIO.deleteFile() attempts to delete a blob via the DataLakeFileClient. Because Iceberg does not require delete to succeed (other FileIO providers ignore failures), any RuntimeException is caught and logged at WARN with the path instead of being thrown.

Source

Thrown at azure/src/main/java/org/apache/iceberg/azure/adlsv2/ADLSFileIO.java:117

  @Override
  public InputFile newInputFile(String path, long length) {
    return new ADLSInputFile(path, length, fileClient(path), azureProperties, metrics);
  }

  @Override
  public OutputFile newOutputFile(String path) {
    return new ADLSOutputFile(path, fileClient(path), azureProperties, metrics);
  }

  @Override
  public void deleteFile(String path) {
    // There is no specific contract about whether delete should fail
    // and other FileIO providers ignore failure.  Log the failure for
    // now as it is not a required operation for Iceberg.
    try {
      fileClient(path).delete();
    } catch (RuntimeException e) {
      LOG.warn("Failed to delete path: {}", path, e);
    }
  }

  @Override
  public Map<String, String> properties() {
    return properties.immutableMap();
  }

  public DataLakeFileSystemClient client(String path) {
    ADLSLocation location = new ADLSLocation(path);
    return client(location);
  }

  @VisibleForTesting
  DataLakeFileSystemClient client(ADLSLocation location) {
    if (clientCache == null) {
      synchronized (this) {
        if (clientCache == null) {

View on GitHub (pinned to 86d9c8fc54)

Solutions

Verify the path exists and the account key/OAuth identity has Storage Blob Data Contributor (delete) rights
Check ADLS account/endpoint configuration in properties
Confirm the file isn't soft-deleted/leased by another process
Use deleteFiles (bulk) if you need a failure count via BulkDeletionFailureException

Defensive patterns

Strategy: fallback

Validate before calling

// pre-check existence and permissions before delete
String account = "https://<account>.dfs.core.windows.net";
DataLakeFileSystemClient fs = new DataLakeFileSystemClientBuilder()
    .endpoint(account).fileSystemName(fsName).credential(cred).buildFileSystemClient();
boolean exists = fs.getFileClient(path).exists();
boolean canDelete = /* verify role assignment 'Storage Blob Data Contributor' */ true;

Try / catch

try {
  io.deleteFile(path);
} catch (RuntimeException e) {
  // ADLSFileIO itself logs; treat delete as best-effort per Iceberg contract
  LOG.warn("Ignoring best-effort delete failure for {}", path, e);
}

Prevention

Grant Storage Blob Data Contributor to the workload identity
Check path existence before delete if strictness is required
Watch WARN logs for repeated delete failures indicating misconfiguration

When it happens

Trigger: Calling FileIO.deleteFile(path) where the ADLS Gen2 path doesn't exist, the credentials lack delete permission, or the storage account is unreachable.

Common situations: Retrying deletion of an already-deleted manifest/data file; misconfigured OAuth roles on the storage account; transient ADLS/network errors during cleanup.

Related errors

AI-assisted analysis of apache/iceberg@86d9c8fc54 (2026-09-12). Data as JSON: /api/errors/690598bce937b93a. Report an issue: GitHub.