apache/hadoop · error · UnsupportedOperationException

{} doesn't support renameSnapshot

Error message

{} doesn't support renameSnapshot

What it means

AbstractFileSystem.renameSnapshot(Path, String, String) is a default stub that throws UnsupportedOperationException with the implementing class name filled in. Renaming snapshots is part of the HDFS-only snapshot API; no other AbstractFileSystem implementation provides it. The error indicates the path is on a filesystem without snapshot support, not that the snapshot name is wrong (that yields SnapshotException on HDFS).

Source

Thrown at hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/AbstractFileSystem.java:1497

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

  /**
   * The specification of this method matches that of
   * {@link FileContext#renameSnapshot(Path, String, String)}.
   *
   * @param path the path.
   * @param snapshotOldName snapshot old name.
   * @param snapshotNewName snapshot new name.
   * @throws IOException raised on errors performing I/O.
   */
  public void renameSnapshot(final Path path, final String snapshotOldName,
      final String snapshotNewName) throws IOException {
    throw new UnsupportedOperationException(getClass().getSimpleName()
        + " doesn't support renameSnapshot");
  }

  /**
   * The specification of this method matches that of
   * {@link FileContext#deleteSnapshot(Path, String)}.
   *
   * @param snapshotDir snapshot dir.
   * @param snapshotName snapshot name.
   * @throws IOException raised on errors performing I/O.
   */
  public void deleteSnapshot(final Path snapshotDir, final String snapshotName)
      throws IOException {
    throw new UnsupportedOperationException(getClass().getSimpleName()
        + " doesn't support deleteSnapshot");
  }

  /**

View on GitHub (pinned to 2add963021)

Solutions

  1. Verify the path scheme is hdfs:// and route snapshot-rename operations there.
  2. Use DistributedFileSystem.renameSnapshot (or the `hdfs dfs -renameSnapshot` shell) so the HDFS-only contract is explicit.
  3. Guard management code by scheme and log/skip on unsupported filesystems.
  4. Catch UnsupportedOperationException as a control-flow signal that this store has no snapshots to rename.

Example fix

// before
fc.renameSnapshot(dir, "daily-1", "daily-2"); // throws on file://

// after
try {
  fc.renameSnapshot(dir, "daily-1", "daily-2");
} catch (UnsupportedOperationException e) {
  LOG.warn("Snapshot rename skipped: {} has no snapshot support", dir);
}
Defensive patterns

Strategy: validation

Validate before calling

static boolean isSnapshotCapable(Path p) {
  String scheme = p.toUri().getScheme();
  return "hdfs".equals(scheme) || "webhdfs".equals(scheme);
}

Try / catch

try {
  fc.renameSnapshot(dir, oldName, newName);
} catch (UnsupportedOperationException e) {
  // store has no snapshots: nothing to rename
}

Prevention

When it happens

Trigger: FileContext.renameSnapshot(path, "old", "new") against local/object-store/ftp schemes, or a viewfs path resolving to a non-HDFS target. Retrying a failed HDFS snapshot workflow after fs.defaultFS was repointed to file:// in a test config.

Common situations: Snapshot lifecycle management (backup rotation scripts renaming daily snapshots) run in local unit tests or against object stores after a config migration; CI environments using file:// as defaultFS.

Related errors


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