apache/hadoop · error · NotInMountpointException

getTrashRoot on path `<path>' is not within a mount point

Error message

getTrashRoot on path `<path>' is not within a mount point

What it means

ViewFileSystem.getTrashRoot(Path) computes the trash location by resolving the path and asking the target file system for its trash root. Any IOException or IllegalArgumentException raised during resolution or trash computation is caught and converted into NotInMountpointException('getTrashRoot on path ... is not within a mount point'), meaning the path cannot be mapped to a backing file system (or the path itself is malformed).

Source

Thrown at hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/viewfs/ViewFileSystem.java:1208

        mountTargetPath = mountTargetPath + "/";
      }

      Path targetFsUserHome = res.targetFileSystem.getHomeDirectory();
      if (targetFSTrashRootPath.startsWith(mountTargetPath) &&
          !(mountTargetPath.equals(ROOT_PATH.toString()) &&
              !res.resolvedPath.equals(ROOT_PATH.toString()) &&
              (targetFsUserHome != null && targetFSTrashRootPath.startsWith(
                  targetFsUserHome.toUri().getPath())))) {
        String relativeTrashRoot =
            targetFSTrashRootPath.substring(mountTargetPath.length());
        return makeQualified(new Path(res.resolvedPath, relativeTrashRoot));
      } else {
        // Return the trash root for the mount point.
        return makeQualified(new Path(res.resolvedPath,
            TRASH_PREFIX + "/" + ugi.getShortUserName()));
      }
    } catch (IOException | IllegalArgumentException e) {
      throw new NotInMountpointException(path, "getTrashRoot");
    }
  }

  /**
   * Get all the trash roots for current user or all users.
   *
   * When FORCE_INSIDE_MOUNT_POINT is set to true, we also return trash roots
   * under the root of each mount point, with their viewFS paths.
   *
   * @param allUsers return trash roots for all users if true.
   * @return all Trash root directories.
   */
  @Override
  public Collection<FileStatus> getTrashRoots(boolean allUsers) {
    // A map from targetFSPath -> FileStatus.
    // FileStatus can be from targetFS or viewFS.
    HashMap<Path, FileStatus> trashRoots = new HashMap<>();
    for (FileSystem fs : getChildFileSystems()) {

View on GitHub (pinned to 2add963021)

Solutions

  1. Mount the user tree: fs.viewfs.mounttable.default.link.user=hdfs://nameservice1/user
  2. Set fs.viewfs.mounttable.default.homedir=/user so trash lookups resolve for the login directory
  3. Run the operation from (or on) a mounted path instead of the viewfs root
  4. If trash is not required for the workflow, bypass it (delete with -skipTrash semantics / move to a mounted scratch dir) or catch NotInMountpointException and fail soft

Example fix

<!-- before: no /user mount, -rm triggers getTrashRoot -> NotInMountpointException -->
<property>
  <name>fs.viewfs.mounttable.default.link.data</name>
  <value>hdfs://nameservice1/data</value>
</property>

<!-- after: add /user and homedir -->
<property>
  <name>fs.viewfs.mounttable.default.link.user</name>
  <value>hdfs://nameservice1/user</value>
</property>
<property>
  <name>fs.viewfs.mounttable.default.homedir</name>
  <value>/user</value>
</property>
Defensive patterns

Strategy: try-catch

Validate before calling

// Verify cwd/home paths are mounted before trash-dependent operations
Path home = fs.getHomeDirectory();
if (!fs.exists(home.getParent())) {
  throw new IllegalStateException("home mount missing: " + home);
}

Try / catch

try {
  Path trash = fs.getTrashRoot(p);
} catch (NotInMountpointException e) {
  // path not mounted or malformed: delete without trash or fail with guidance
  throw new IOException(p + " is not under a viewfs mount; mount it or bypass trash", e);
}

Prevention

When it happens

Trigger: A delete/move that must consult the trash root for a working directory such as /user/<name> when /user is not mounted; getTrashRoot on a path outside every mount link; paths that trigger IllegalArgumentException during URI normalization (empty segments, embedded '..' escaping the mount, bad characters); target FS I/O errors while locating .Trash.

Common situations: Shell users running `hadoop fs -rm` after a viewfs migration where fs.viewfs.mounttable.default.homedir or the /user mount was never configured; scripts operating from '/' as cwd; mount tables that cover only /data and /tmp.

Related errors


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