eclipse-vertx/vert.x · error · FileSystemException

Accessed denied for chown on ${path}

Error message

Accessed denied for chown on ${path}

What it means

Vert.x wraps a SecurityException thrown by Files.setOwner (or the principal lookup) during FileSystem.chown into this FileSystemException. A SecurityManager or OS-level authorization refused the owner change on the target path. The message intentionally mirrors the chmod 'Accessed denied' variant.

Source

Thrown at vertx-core/src/main/java/io/vertx/core/file/impl/FileSystemImpl.java:577

      public Void perform() {
        try {
          Path target = resolveFile(path).toPath();
          UserPrincipalLookupService service = target.getFileSystem().getUserPrincipalLookupService();
          UserPrincipal userPrincipal = user == null ? null : service.lookupPrincipalByName(user);
          GroupPrincipal groupPrincipal = group == null ? null : service.lookupPrincipalByGroupName(group);
          if (groupPrincipal != null) {
            PosixFileAttributeView view = Files.getFileAttributeView(target, PosixFileAttributeView.class, LinkOption.NOFOLLOW_LINKS);
            if (view == null) {
              throw new FileSystemException("Change group of file not supported");
            }
            view.setGroup(groupPrincipal);

          }
          if (userPrincipal != null) {
            Files.setOwner(target, userPrincipal);
          }
        } catch (SecurityException e) {
          throw new FileSystemException("Accessed denied for chown on " + path);
        } catch (IOException e) {
          throw new FileSystemException(getFileAccessErrorMessage("crown", path), e);
        }
        return null;
      }
    };
  }

  private BlockingAction<FileProps> propsInternal(String path) {
    return props(path, true);
  }

  private BlockingAction<FileProps> lpropsInternal(String path) {
    return props(path, false);
  }

  private BlockingAction<FileProps> props(String path, boolean followLinks) {
    Objects.requireNonNull(path);

View on GitHub (pinned to fb308bd8c3)

Solutions

  1. Run the process as root or grant CAP_CHOWN (docker run --cap-add=CHOWN) when ownership changes are genuinely required.
  2. Avoid chown entirely: create the file with the correct owner from the start (same user writes it).
  3. Verify the target path's current owner with fileProps and skip chown when it already matches.
  4. Review the active SecurityManager policy file and grant FilePermission/PropertyPermission as needed.

Example fix

// before
vertx.fileSystem().chown("/app/data", "appuser", null); // SecurityException as non-root
// after
FileProps p = vertx.fileSystem().propsBlocking("/app/data");
if (!"appuser".equals(p.owner())) {
  vertx.fileSystem().chown("/app/data", "appuser", null);
}
Defensive patterns

Strategy: try-catch

Validate before calling

FileProps props = vertx.fileSystem().propsBlocking(path);
// skip chown if current owner already matches
desiredOwner.equals(props.owner()) -> no-op

Try / catch

try { vertx.fileSystem().chownBlocking(path, user, null); } catch (FileSystemException e) { throw new IllegalStateException("chown requires elevated privileges; run as root or add CAP_CHOWN", e); }

Prevention

When it happens

Trigger: Calling vertx.fileSystem().chown(path, user, null or group) while a SecurityManager checkAccess(owner) fails, or the JVM user lacks the OS privilege (root/CAP_CHOWN) required to change file ownership.

Common situations: Running as a non-root container user while setup code tries to chown files created by another uid; restrictive SecurityManager policies in legacy application servers; changing ownership of files owned by other users.

Understand the failure class

Background: Permission denied / not authorized / 403 Forbidden: access-control rejections when the caller lacks the required role, grant, or ownership — this error's family across 18 libraries.

Related errors


AI-assisted analysis of eclipse-vertx/vert.x@fb308bd8c3 (2026-09-06). Data as JSON: /api/errors/62a9e5354ad29fbd. Report an issue: GitHub.