AllMC 1.7.xMC 1.12.xMC 1.16.xMC 1.19.x

Permission denied / AccessDeniedException

When Minecraft logs 'java.nio.file.AccessDeniedException' or 'Permission denied', the JVM tried to write a file it doesn't own. On Linux servers (which is most of them) this is almost always a file-ownership mismatch — usually after a manual SFTP upload, a backup restore from the wrong account, or a Docker container running as a non-root user opening a file written by root.

Fastest path: paste your crash report into the Crash Doctor — it identifies this pattern and 40+ others automatically. No signup.

How to fix it

  1. 1

    Find the file the JVM failed on

    The error usually names the path. Common targets: config/something.toml after a manual edit, world/playerdata/UUID.dat after a restore, mods/SomeMod.jar after an SFTP drop. That file (or its parent dir) has the wrong owner.

  2. 2

    Contact support to re-chown if you're on hosted

    On a hosted server you usually don't have shell access to chown files. Open a support ticket: 'Permission denied on path X — please chown to the Minecraft user'. Most hosts (us included) re-chown for free, takes 5 minutes.

  3. 3

    On self-hosted: chown -R the server dir to the MC user

    If you control the box: 'sudo chown -R minecraft:minecraft /opt/minecraft-server' (substitute your user/group + path). One command fixes the whole tree. Then restart the server.

  4. 4

    Audit how the wrong file landed there

    Once fixed, find out which workflow created the wrong ownership. Manual SFTP as root? A backup tool running as a different user? A cronjob restoring from the wrong account? Patch the workflow so it doesn't happen again — re-chown every week is not a fix.

Alternative causes

These can produce the same error message — worth ruling out if the steps above don't resolve it.

Read-only filesystem (rare, but happens after kernel panic)

If the underlying VM's filesystem went read-only (kernel detected corruption, IO errors, etc.), every write fails with 'Permission denied'. df -h still shows space free but mount shows ro. Fix is host-side: fsck + remount.

SELinux / AppArmor blocking the write

On distributions with mandatory access control (RHEL, Ubuntu Pro), an SELinux context mismatch can produce the same symptom. Check 'audit2allow' output. Less common on standard hosting; if you got here, you already know.

Frequently asked

Can a player cause Permission denied?

Indirectly — a player command that triggers a mod to write a new file (worldedit save, custom scoreboard backup) may fail if the target dir has wrong ownership. But the root cause is still ownership; the player just exposes it.

Why does this happen after restoring a backup?

Backup tools often run as root or a different user. When they unpack, the restored files own as whatever ran the unpack — usually NOT the Minecraft user. Chown after restore is a mandatory step.

Will running Minecraft as root fix it?

It will hide the symptom, but it's a terrible idea. A modded server running as root can be exploited to root-level RCE through a single bad mod. Fix the ownership instead.

Want this auto-fixed on your server?

CoalHosting's Minecraft hosting runs the same pattern database against every crash and applies the known fix before your players notice. Free crash diagnosis works on any server, hosted or not.

Related crashes

Last reviewed 2026-06-05. If a step is wrong or out of date, tell us — we'll fix the article and the auto-pattern at the same time.