apache/hadoop · error · IOException

rename from {} to {} failed.

Error message

rename from {} to {} failed.

What it means

The final step of the deprecated options-aware rename calls the abstract rename(src, dst) and converts a false return into IOException('rename from src to dst failed.'). All path preconditions already passed, so false means the filesystem itself refused the move - most often permissions or an OS-level lock, since boolean renames carry no reason.

Source

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

          throw new IOException(
              "rename cannot overwrite non empty destination directory " + dst);
        }
      }
      delete(dst, false);
    } else {
      final Path parent = dst.getParent();
      final FileStatus parentStatus = getFileStatus(parent);
      if (parentStatus == null) {
        throw new FileNotFoundException("rename destination parent " + parent
            + " not found.");
      }
      if (!parentStatus.isDirectory()) {
        throw new ParentNotDirectoryException("rename destination parent " + parent
            + " is a file.");
      }
    }
    if (!rename(src, dst)) {
      throw new IOException("rename from " + src + " to " + dst + " failed.");
    }
  }

  /**
   * Truncate the file in the indicated path to the indicated size.
   * <ul>
   *   <li>Fails if path is a directory.</li>
   *   <li>Fails if path does not exist.</li>
   *   <li>Fails if path is not closed.</li>
   *   <li>Fails if new size is greater than current size.</li>
   * </ul>
   * @param f The path to the file to be truncated
   * @param newLength The size the file is to be truncated to
   *
   * @return <code>true</code> if the file has been truncated to the desired
   * <code>newLength</code> and is immediately available to be reused for
   * write operations such as <code>append</code>, or
   * <code>false</code> if a background process of adjusting the length of

View on GitHub (pinned to 2add963021)

Solutions

1. Check write permission on both parents for the effective user (and kinit for Kerberos clusters)
2. Close any open streams/handles on src before renaming (especially local FS on Windows)
3. Inspect the concrete FileSystem's logs for the store-level reason
4. For stores with non-atomic rename, fall back to copy + delete with explicit error handling

Example fix

// before
fs.rename(src, dst); // underlying false -> IOException: rename ... failed

// after
if (!fs.rename(src, dst)) {
  FileContext.getFileContext(conf).util().copy(src, dst); // copy fallback
  fs.delete(src, false);
}

try {
  fs.rename(src, dst, Rename.OVERWRITE);
} catch (IOException e) {
  if (e.getMessage() != null && e.getMessage().contains("rename from")) {
    // preconditions passed but store refused: check perms/locks, then copy+delete
    FileContext.getFileContext(conf).util().copy(src, dst);
    fs.delete(src, false);
  } else {
    throw e;
  }
}

When it happens

Trigger: Underlying rename(Path, Path) returning false: no write permission on the source or destination parent in the store; the source file is open/locked (notably Windows local FS); store errors mapped to false by some object-store clients.

Common situations: Running as a user without write access to the destination directory; local tests on Windows moving open files; HDFS lease or safe-mode edge cases surfacing as a false return.

Related errors

• Cannot overwrite an existing file: %s
• Cannot rename because path does not exist: %s
• Rename unsuccessful : '%s' to '%s'
• The source {src} and destination {dst} are the same
• mkdir of ${f} failed

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