apache/hadoop · error · PathIOException

Input/output error

Error message

Input/output error

What it means

Rename.processPath (MoveCommands.java:126) throws PathIOException (default message 'Input/output error') when target.fs.rename(src, target) returns false. The inline comment admits 'we have no way to know the actual error...' — the boolean return discards the reason, so any FS-level refusal lands here.

Source

Thrown at hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/shell/MoveCommands.java:126

      getRemoteDestination(args);
    }

    @Override
    protected void processPath(PathData src, PathData target) throws IOException {
      String srcUri = src.fs.getUri().getScheme() + "://" +
          src.fs.getUri().getHost();
      String dstUri = target.fs.getUri().getScheme() + "://" +
          target.fs.getUri().getHost();
      if (!srcUri.equals(dstUri)) {
        throw new PathIOException(src.toString(),
            "Does not match target filesystem");
      }
      if (target.exists) {
        throw new PathExistsException(target.toString());
      }
      if (!target.fs.rename(src.path, target.path)) {
        // we have no way to know the actual error...
        throw new PathIOException(src.toString());
      }
    }
  }
}

View on GitHub (pinned to 2add963021)

Solutions

  1. Check WRITE permission on the destination's parent directory and fix ownership ('hadoop fs -chown'/'-chmod' as owner or via admin)
  2. Confirm the source still exists ('hadoop fs -ls <src>') — it may have been moved/deleted concurrently
  3. Check NameNode logs and quota state ('hdfs dfsadmin -quotas' path-level via 'hdfs dfs -count -q') for the underlying refusal
  4. Retry once the transient cause (failover, concurrent job) clears; the two earlier guards make stale-target causes unlikely

Example fix

# diagnose: rename returned false without a reason
hadoop fs -ls /final            # parent perms + does source still exist?
hadoop fs -count -q /final      # namespace quota remaining
hadoop fs -chmod ...            # grant write, then re-run mv
Defensive patterns

Strategy: retry

Validate before calling

// pre-flight the three common false-causes
if (!fs.exists(src)) throw new FileNotFoundException(src.toString());
if (!fs.getFileStatus(dst.getParent()).isDirectory()) throw new IOException("dst parent missing");
// ensure WRITE on dst parent via permissions check before calling rename

Try / catch

catch (PathIOException e) { diagnose: source still present? dst-parent writable? quota remaining?; fix cause then retry rename exactly once }

Prevention

When it happens

Trigger: FileSystem.rename returning false after the same-FS and target-not-exists checks passed: no WRITE permission on the destination parent, source deleted by a concurrent process between enumeration and rename, namespace quota exceeded on the destination directory, or the destination parent disappearing mid-operation.

Common situations: Moving data into directories owned by another user; concurrent jobs racing over the same files; renames during safe mode or NN failover returning false; quota-limited landing zones in ingestion pipelines.

Related errors


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