apache/hadoop · error · HadoopIllegalArgumentException

Invalid type of acl in <aclSpec> :

Error message

Invalid type of acl in <aclSpec> :

What it means

The token following the optional "default:" scope must name one of the AclEntryType enum values — user, group, mask, other (matched case-insensitively via Enum.valueOf after uppercasing). Any other token raises IllegalArgumentException, which is converted to HadoopIllegalArgumentException("Invalid type of acl in <aclSpec> : ...").

Source

Thrown at hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/permission/AclEntry.java:291

    int index = 0;
    if ("default".equals(split[0])) {
      // default entry
      index++;
      builder.setScope(AclEntryScope.DEFAULT);
    }

    if (split.length <= index) {
      throw new HadoopIllegalArgumentException("Invalid <aclSpec> : " + aclStr);
    }

    AclEntryType aclType = null;
    try {
      aclType = Enum.valueOf(
          AclEntryType.class, StringUtils.toUpperCase(split[index]));
      builder.setType(aclType);
      index++;
    } catch (IllegalArgumentException iae) {
      throw new HadoopIllegalArgumentException(
          "Invalid type of acl in <aclSpec> :" + aclStr);
    }

    if (split.length > index) {
      String name = split[index];
      if (!name.isEmpty()) {
        builder.setName(name);
      }
      index++;
    }

    if (includePermission) {
      if (split.length <= index) {
        throw new HadoopIllegalArgumentException("Invalid <aclSpec> : "
            + aclStr);
      }
      String permission = split[index];
      FsAction fsAction = FsAction.getFsAction(permission);

View on GitHub (pinned to 2add963021)

Solutions

1. Correct the type token to one of user, group, mask, other (optionally after the default: prefix)
2. Validate the type token in user-supplied specs before parsing (see typeGuard)
3. Generate entries with AclEntry.Builder and AclEntryType constants instead of string parsing

Example fix

// before
AclEntry e = AclEntry.parseAclEntry("usr:foo:rwx", true);   // Invalid type of acl

// after
AclEntry e = AclEntry.parseAclEntry("user:foo:rwx", true); // valid type token

private static final Set<String> ACL_TYPES =
    Set.of("user", "group", "mask", "other");

String[] parts = aclSpec.split(":");
int i = "default".equals(parts[0]) ? 1 : 0;
if (parts.length <= i || !ACL_TYPES.contains(parts[i].toLowerCase(Locale.ROOT))) {
  throw new IllegalArgumentException("acl type must be user|group|mask|other: " + aclSpec);
}

// type guard: is this string a parseable Hadoop ACL entry type token?
static boolean isValidAclTypeToken(String token) {
  if (token == null) { return false; }
  switch (token.toLowerCase(Locale.ROOT)) {
    case "user": case "group": case "mask": case "other":
      return true;
    default:
      return false;
  }
}

catch HadoopIllegalArgumentException from parseAclEntry, check for "Invalid type of acl", and correct the type token (user/group/mask/other) before reparsing; keep the original spec in the error report.

When it happens

Trigger: Typos like "usr:foo:rwx" or "users:foo"; a name-only spec ("foo:rwx") shifting the name into the type slot; missing delimiters from concatenation shifting every field left; tokens with unexpected case that still should match (they do, but anything else fails).

Common situations: Hand-written ACL strings in scripts and docs; migrating from POSIX setfacl syntax (u:foo:rw, g::r) where abbreviations are legal; specs built by string concatenation where one ':' goes missing.

Related errors

• Invalid <aclSpec> :
• value cannot be blank
• ${value} is not in expected format.Expected format is <numbe
• Bad HTML quoting for {}
• User {} can not be added

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