apache/hadoop · error · UnsupportedOperationException

{} doesn't support renameSnapshot

Error message

{} doesn't support renameSnapshot

What it means

FileSystem.renameSnapshot(Path, String, String) is optional; the base class throws UnsupportedOperationException with getClass().getSimpleName() + " doesn't support renameSnapshot". Only the HDFS snapshot implementations override it (DistributedFileSystem, WebHdfsFileSystem, and ViewFileSystem/ChRootedFileSystem/FilterFileSystem pass-throughs).

Source

Thrown at hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/FileSystem.java:3118

   */
  public Path createSnapshot(Path path, String snapshotName)
      throws IOException {
    throw new UnsupportedOperationException(getClass().getSimpleName()
        + " doesn't support createSnapshot");
  }

  /**
   * Rename a snapshot.
   * @param path The directory path where the snapshot was taken
   * @param snapshotOldName Old name of the snapshot
   * @param snapshotNewName New name of the snapshot
   * @throws IOException IO failure
   * @throws UnsupportedOperationException if the operation is unsupported
   *         (default outcome).
   */
  public void renameSnapshot(Path path, String snapshotOldName,
      String snapshotNewName) throws IOException {
    throw new UnsupportedOperationException(getClass().getSimpleName()
        + " doesn't support renameSnapshot");
  }

  /**
   * Delete a snapshot of a directory.
   * @param path  The directory that the to-be-deleted snapshot belongs to
   * @param snapshotName The name of the snapshot
   * @throws IOException IO failure
   * @throws UnsupportedOperationException if the operation is unsupported
   *         (default outcome).
   */
  public void deleteSnapshot(Path path, String snapshotName)
      throws IOException {
    throw new UnsupportedOperationException(getClass().getSimpleName()
        + " doesn't support deleteSnapshot");
  }

  /**

View on GitHub (pinned to 2add963021)

Solutions

  1. Guard with fs.hasPathCapability(dir, CommonPathCapabilities.FS_SNAPSHOTS) or instanceof DistributedFileSystem
  2. Point the tooling at the HDFS namespace it was written for (fix fs.defaultFS / explicit hdfs:// path)
  3. Catch UnsupportedOperationException and skip the rename step for stores without snapshot support
  4. Track snapshot names in your own catalog so renames become metadata-only operations

Example fix

// before
fs.renameSnapshot(dir, "snap-old", "snap-new");
// throws on non-HDFS stores

// after
if (fs instanceof DistributedFileSystem) {
  fs.renameSnapshot(dir, "snap-old", "snap-new");
} else {
  catalog.renameSnapshot(dir, "snap-old", "snap-new"); // metadata indirection
}
Defensive patterns

Strategy: try-catch

Validate before calling

if (fs.hasPathCapability(dir, CommonPathCapabilities.FS_SNAPSHOTS)) {
  fs.renameSnapshot(dir, oldName, newName);
}

Type guard

static boolean supportsSnapshotRename(FileSystem fs) {
  return fs instanceof DistributedFileSystem;
}

Try / catch

try {
  fs.renameSnapshot(dir, oldName, newName);
} catch (UnsupportedOperationException e) {
  LOG.warn("Snapshot rename unsupported on {}; keeping name {}", fs.getUri(), oldName);
}

Prevention

When it happens

Trigger: Calling fs.renameSnapshot(dir, oldName, newName) on LocalFileSystem, S3A, ABFS, GCS, HarFileSystem, or any custom FileSystem that did not override the method; snapshot-management scripts run against a non-HDFS URI.

Common situations: Lifecycle automation that renames dated snapshots (snap-2024-01-01 -> snap-current) executed in the wrong environment; the same code path working on the HDFS cluster but failing in local integration tests.

Related errors


AI-assisted analysis of apache/hadoop@2add963021 (2026-08-22). Data as JSON: /api/errors/255f0b0bd7f303b4. Report an issue: GitHub.