apache/hadoop · error · IOException

Can't get path for handle path: {}

Error message

Can't get path for handle path: {}

What it means

Thrown by RpcProgramNfs3.readdir() while servicing an NFS3 READDIR request with cookie == 0: the gateway resolves the parent entry ('..') of the directory being listed via dfsClient.getFileInfo(dirFileIdPath + "/..") to compute dotdotFileId, and getFileInfo returns null. The source marks it 'This should not happen' — it means the gateway's HDFS client could not resolve an inode-by-id path that ought to exist, so the IOException escapes the handler as an IO error back to the NFS client.

Source

Thrown at hadoop-hdfs-project/hadoop-hdfs-nfs/src/main/java/org/apache/hadoop/hdfs/nfs/nfs3/RpcProgramNfs3.java:1619

              "mismatches.");
        } else {
          LOG.error("CookieVerf mismatch. request cookieVerf: {} " +
              "dir cookieVerf: {}",
              cookieVerf, dirStatus.getModificationTime());
          return new READDIR3Response(
              Nfs3Status.NFS3ERR_BAD_COOKIE,
              Nfs3Utils.getFileAttr(dfsClient, dirFileIdPath, iug));
        }
      }

      if (cookie == 0) {
        // Get dotdot fileId
        String dotdotFileIdPath = dirFileIdPath + "/..";
        HdfsFileStatus dotdotStatus = dfsClient.getFileInfo(dotdotFileIdPath);

        if (dotdotStatus == null) {
          // This should not happen
          throw new IOException("Can't get path for handle path: "
              + dotdotFileIdPath);
        }
        dotdotFileId = dotdotStatus.getFileId();
      }

      // Get the list from the resume point
      byte[] startAfter;
      if(cookie == 0 ) {
        startAfter = HdfsFileStatus.EMPTY_NAME;
      } else {
        String inodeIdPath = Nfs3Utils.getFileIdPath(cookie);
        startAfter = inodeIdPath.getBytes(StandardCharsets.UTF_8);
      }

      dlisting = listPaths(dfsClient, dirFileIdPath, startAfter);
      postOpAttr = Nfs3Utils.getFileAttr(dfsClient, dirFileIdPath, iug);
      if (postOpAttr == null) {
        LOG.error("Can't get path for fileId: {}", handle.getFileId());

View on GitHub (pinned to 2add963021)

Solutions

1. Retry the listing from the NFS client — if the directory was removed the handle is ESTALE and a re-lookup of the path is the correct behavior
2. Verify the directory still exists: hdfs dfs -ls <path>, and check whether another job deleted/renamed it mid-listing
3. Check the NFS gateway log and its NameNode connectivity (failed RPCs make getFileInfo return null for valid paths)
4. Restart the NFS gateway if its DFSClient is wedged after an HDFS restart, HA failover, or upgrade

// In NFS3 handler wrappers: convert listing failures into NFS-level errors, not dropped RPCs
try {
  response = readdir(xdr, securityHandler, client);
} catch (IOException e) {
  LOG.warn("READDIR failed for handle: {}", handle, e);
  return new READDIR3Response(Nfs3Status.NFS3ERR_IO); // client retries / re-lookups
}

When it happens

Trigger: An NFS client starts a fresh listing (cookie 0) of a directory handle; concurrently the directory (or an ancestor) is deleted or renamed in HDFS so the '..' inode-by-id path no longer resolves, or the gateway's DFSClient is unhealthy (lost NameNode connection after failover/upgrade) and getFileInfo returns null for an otherwise valid path.

Common situations: Cleanup or compaction jobs deleting directories while an NFS-mounted client (ls, rsync, backup) is listing them; the NFS gateway surviving an HDFS restart/failover with a stale DFSClient; heavy rename churn under the listed path.

Related errors

• Interrupted while running disk check
• Cannot create dump directory {}
• Null IO stream
• Interrupted while copying objects (copy)
• Task set failed with an uncaught throwable

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