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
- Run the process as root or grant CAP_CHOWN (docker run --cap-add=CHOWN) when ownership changes are genuinely required.
- Avoid chown entirely: create the file with the correct owner from the start (same user writes it).
- Verify the target path's current owner with fileProps and skip chown when it already matches.
- 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
- Run the app as the user that should own the files
- Avoid chown in non-root containers
- Prefer volume-configuration over runtime chown
- Skip chown when owner already matches
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
- Change group of file not supported
- Failed to crown ${path}
- Class not allowed:
- Class not allowed:
- Failed to truncate ${p}
AI-assisted analysis of eclipse-vertx/vert.x@fb308bd8c3 (2026-09-06).
Data as JSON: /api/errors/62a9e5354ad29fbd.
Report an issue: GitHub.