apache/hadoop · error · IOException

Failed to get server trash configuration

Error message

Failed to get server trash configuration

What it means

Thrown by Trash.moveToAppropriateTrash (reached from 'hadoop fs -rm' via the Delete shell command when trash is enabled). Before moving anything, Hadoop asks the fully-resolved FileSystem for getServerDefaults(path).getTrashInterval() so server-side trash policy wins over client config. Any exception there is deliberately fatal: the code prefers failing over deleting a file that server-side trash might have preserved.

Source

Thrown at hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/Trash.java:97

    Path fullyResolvedPath = fs.resolvePath(p);
    FileSystem fullyResolvedFs =
        FileSystem.get(fullyResolvedPath.toUri(), conf);
    // If the trash interval is configured server side then clobber this
    // configuration so that we always respect the server configuration.
    try {
      long trashInterval = fullyResolvedFs.getServerDefaults(
          fullyResolvedPath).getTrashInterval();
      if (0 != trashInterval) {
        Configuration confCopy = new Configuration(conf);
        confCopy.setLong(CommonConfigurationKeysPublic.FS_TRASH_INTERVAL_KEY,
            trashInterval);
        conf = confCopy;
      }
    } catch (Exception e) {
      // If we can not determine that trash is enabled server side then
      // bail rather than potentially deleting a file when trash is enabled.
      LOG.warn("Failed to get server trash configuration", e);
      throw new IOException("Failed to get server trash configuration", e);
    }

    /*
     * In HADOOP-18144, we changed getTrashRoot() in ViewFileSystem to return a
     * viewFS path, instead of a targetFS path. moveToTrash works for
     * ViewFileSystem now. ViewFileSystem will do path resolution internally by
     * itself.
     *
     * When localized trash flag is enabled:
     *    1). if fs is a ViewFileSystem, we can initialize Trash() with a
     *        ViewFileSystem object;
     *    2). When fs is not a ViewFileSystem, the only place we would need to
     *        resolve a path is for symbolic links. However, symlink is not
     *        enabled in Hadoop due to the complexity to support it
     *        (HADOOP-10019).
     */
    if (conf.getBoolean(CONFIG_VIEWFS_TRASH_FORCE_INSIDE_MOUNT_POINT,
        CONFIG_VIEWFS_TRASH_FORCE_INSIDE_MOUNT_POINT_DEFAULT)) {

View on GitHub (pinned to 2add963021)

Solutions

1. Read the cause chain (getCause()) - UnsupportedOperationException means the FS cannot report trash config; RPC/ConnectException means fix connectivity
2. Fix the underlying FileSystem access: valid fs.defaultFS, reachable NameNode, fresh Kerberos credentials, correct viewfs mounts
3. If the filesystem legitimately cannot report server trash config, delete with trash explicitly disabled for that path/store (e.g. -skipTrash) after confirming you accept permanent deletion

// fail fast with context before any delete that may route through trash
try {
  org.apache.hadoop.fs.FsServerDefaults d = fs.getServerDefaults(p);
  // d.getTrashInterval() is what Trash will read
} catch (Exception e) {
  throw new IOException("Cannot determine server trash policy for " + p
      + "; fix FS connectivity/config before deleting", e);
}

try {
  fs.delete(p, true); // 'hadoop fs -rm' equivalent
} catch (IOException e) {
  if (e.getMessage() != null
      && e.getMessage().equals("Failed to get server trash configuration")) {
    Throwable c = e.getCause();
    // UnsupportedOperationException -> FS cannot report defaults
    // java.net.ConnectException / RemoteException -> fix NN access/auth
  }
}

When it happens

Trigger: 'hadoop fs -rm' with fs.trash.interval > 0 against a FileSystem whose getServerDefaults throws: NameNode unreachable/RPC failure, authenticated-but-unauthorized, or a connector (object store, ViewFileSystem with a bad mount) that raises UnsupportedOperationException.

Common situations: Object-store connectors whose server-defaults endpoint is unsupported; transient NN outage during cleanup jobs; misconfigured fs.defaultFS or viewfs mount tables; expired Kerberos tickets during long-running cleanup.

Related errors

• Cannot move "{path}" to the trash, as it contains the trash
• Directory {} is not empty.
• Can not delete root path
• Can not delete the directory: [%s], as it is not empty and o
• {path}

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