“Access Denied” on Your Own Files After Reinstall: The Ownership Fix

What’s actually happening: names lie, numbers don’t

Linux file ownership is stored as numeric identifiers: UID (user ID) and GID (group ID). The string “alice” is just a lookup in /etc/passwd (or LDAP/SSSD). Your file says “owned by UID 1001.” Your system translates 1001 into a name if it can. After reinstall, “alice” might now be UID 1000, and 1001 might belong to nobody—or worse, to a different account.

So you log in as “alice,” but your files are owned by “UID 1001,” and your new “alice” is UID 1000. The kernel checks numbers, not feelings. The check fails. You get “Permission denied.”

That’s the main story. But production systems have plot twists:

• ACLs can override the classic rwx bits. You can “own” the file and still be denied.
• Filesystem mount options can mask or invent ownership (common on FAT/NTFS/CIFS).
• Network filesystems can rewrite identity (NFS idmapping, root squash, Kerberos).
• Encryption layers can change who can open what (eCryptfs, fscrypt, LUKS is usually fine).
• SELinux/AppArmor can say “no” even when permissions say “yes”.

And yes, you can “fix” it with chmod 777. You can also fix your car by removing the brakes. Both approaches are fast and educational.

One quote worth keeping in your head when you’re tempted to bulldoze permissions: “Hope is not a strategy.” — Gene Kranz.

Fast diagnosis playbook (check these first)

This is the fastest path to the bottleneck. Do these in order. Each step tells you whether you’re dealing with UID/GID mismatch, ACLs, mount semantics, or security layers.

1) Confirm the error is permission/ownership, not disk or corruption

• If reads work but writes fail: likely ownership/ACL/mount read-only.
• If both reads and stats fail: possibly mount issue, encryption key missing, or filesystem damage.

2) Check who you are (numbers) and who owns the file (numbers)

• If your UID differs from the file’s UID: you have the classic reinstall mismatch.
• If numbers match but still denied: look at ACLs, immutable flags, SELinux/AppArmor, or mount options.

3) Check mount type and options

• FAT/NTFS/CIFS often “fake” ownership. Your chown might do nothing.
• NFS can map identities; “nobody” ownership is a big clue.
• Read-only mounts happen after journal recovery failures, unsafe shutdowns, or explicit ro.

4) Check ACLs and attributes

• ACL denies are common in enterprise desktops and shared team directories.
• The immutable bit (chattr +i) is rare but unforgettable.

5) Only then apply the fix

• Prefer targeted chown over recursive carpet-bombing.
• Prefer numeric ownership changes when you’re migrating across systems.
• Don’t “fix” mounts that don’t support ownership by forcing chown; you’ll waste time.

Practical tasks: commands, outputs, decisions

Below are real tasks you can run. Each includes: the command, what the output means, and the decision you make. Run them from a shell with appropriate privileges. When in doubt, start read-only and escalate carefully.

Task 1: Verify your current numeric identity

cr0x@server:~$ id
uid=1000(cr0x) gid=1000(cr0x) groups=1000(cr0x),27(sudo),118(lpadmin)

Meaning: Your account is UID 1000, primary GID 1000. These numbers are what the kernel uses for permission checks.

Decision: Keep these numbers handy; you’ll compare them to file ownership.

Task 2: Inspect a failing file with numeric owners

cr0x@server:~$ ls -ln /mnt/oldhome/cr0x/Documents/report.txt
-rw------- 1 1001 1001 8421 Jan 12 09:14 /mnt/oldhome/cr0x/Documents/report.txt

Meaning: The file is owned by UID 1001 and GID 1001. Your current user is 1000. This mismatch is the smoking gun.

Decision: Plan to change ownership from 1001:1001 to 1000:1000 (or to the correct target user/group).

Task 3: Confirm what UID 1001 maps to on this system

cr0x@server:~$ getent passwd 1001

Meaning: No output means UID 1001 is not assigned to any user on this system.

Decision: Safe to reassign ownership away from 1001, assuming 1001 corresponds to your old account on the old install.

Task 4: Check the filesystem type and mount options

cr0x@server:~$ findmnt -no SOURCE,FSTYPE,OPTIONS /mnt/oldhome
/dev/sdb2 ext4 rw,relatime

Meaning: ext4 supports Unix ownership and permissions. chown will work as expected.

Decision: Proceed with ownership fixes on the filesystem level.

Task 5: Detect read-only mounts (silent permission killers)

cr0x@server:~$ mount | grep ' /mnt/oldhome '
/dev/sdb2 on /mnt/oldhome type ext4 (rw,relatime)

Meaning: It’s mounted read-write (rw). If you saw ro, writes would fail regardless of ownership.

Decision: If ro, remount rw (after checking logs) instead of chasing permissions.

Task 6: Try a non-destructive write test

cr0x@server:~$ touch /mnt/oldhome/cr0x/.permtest
touch: cannot touch '/mnt/oldhome/cr0x/.permtest': Permission denied

Meaning: The directory denies write for your UID. That aligns with the ownership mismatch.

Decision: Fix ownership of the directory tree (or at least the writable paths you need).

Task 7: Check directory ownership and mode (directories are the gate)

cr0x@server:~$ ls -ldn /mnt/oldhome/cr0x
drwx------ 72 1001 1001 4096 Feb  1 18:22 /mnt/oldhome/cr0x

Meaning: Directory is 0700 owned by 1001. Only UID 1001 can read/write/enter it.

Decision: Ownership must change, otherwise nothing inside matters.

Task 8: Preview what you are about to change (find by numeric UID)

cr0x@server:~$ sudo find /mnt/oldhome/cr0x -xdev -uid 1001 -maxdepth 2 -printf '%u:%g %m %p\n' | head
1001:1001 700 /mnt/oldhome/cr0x
1001:1001 700 /mnt/oldhome/cr0x/.ssh
1001:1001 600 /mnt/oldhome/cr0x/.ssh/authorized_keys
1001:1001 644 /mnt/oldhome/cr0x/.bashrc
1001:1001 700 /mnt/oldhome/cr0x/Documents

Meaning: You’re seeing the shape of the change. The -xdev keeps you on that filesystem (important if ~/ contains mounts).

Decision: If the list looks right, proceed. If it includes unexpected paths (like mounted backups), stop and refine.

Task 9: Fix ownership safely (targeted, recursive, staying on one filesystem)

cr0x@server:~$ sudo chown -R --from=1001:1001 1000:1000 /mnt/oldhome/cr0x

Meaning: This changes ownership only if the current owner/group match 1001:1001. That prevents “oops, I changed someone else’s files.”

Decision: Use --from whenever you’re migrating ownership across reinstalls. It’s a seatbelt that actually works.

Task 10: Re-test write access

cr0x@server:~$ touch /mnt/oldhome/cr0x/.permtest
cr0x@server:~$ ls -l /mnt/oldhome/cr0x/.permtest
-rw-r--r-- 1 cr0x cr0x 0 Feb  4 10:11 /mnt/oldhome/cr0x/.permtest

Meaning: You can write now; ownership and permissions align with your current identity.

Decision: Remove the test file and proceed to validate special directories like .ssh.

Task 11: Verify and harden .ssh permissions (common post-fix breakage)

cr0x@server:~$ chmod 700 /mnt/oldhome/cr0x/.ssh
cr0x@server:~$ chmod 600 /mnt/oldhome/cr0x/.ssh/authorized_keys
cr0x@server:~$ ls -ld /mnt/oldhome/cr0x/.ssh
drwx------ 2 cr0x cr0x 4096 Feb  4 10:08 /mnt/oldhome/cr0x/.ssh

Meaning: SSH is picky; it expects tight modes. Ownership fixes sometimes leave group-write bits around, and SSH will refuse to use keys.

Decision: Normalize .ssh now so you’re not debugging “Permission denied (publickey)” later.

Task 12: Check for ACLs that can still deny access

cr0x@server:~$ getfacl -p /mnt/oldhome/cr0x/Documents | sed -n '1,20p'
# file: /mnt/oldhome/cr0x/Documents
# owner: cr0x
# group: cr0x
user::rwx
group::---
other::---
default:user::rwx
default:group::---
default:other::---

Meaning: No surprise deny ACLs here; it’s essentially 0700 semantics with default ACLs for new files.

Decision: If you see entries like user:cr0x:--- or an ACL mask restricting, fix ACLs rather than chmod’ing blindly.

Task 13: If ownership “won’t change,” confirm you’re not on NTFS/FAT or CIFS

cr0x@server:~$ findmnt -no FSTYPE,OPTIONS /mnt/share
cifs rw,relatime,vers=3.1.1,cache=strict,username=cr0x,uid=1000,gid=1000,file_mode=0644,dir_mode=0755

Meaning: CIFS presents ownership via mount options. chown typically won’t persist because the server controls it (or the client fakes it).

Decision: Fix ownership/permissions on the server side (Samba/Windows ACLs) or adjust mount options (uid=, gid=, file_mode=, dir_mode=).

Task 14: If NFS shows “nobody,” check idmapping

cr0x@server:~$ ls -ln /mnt/nfs/home/cr0x | head
drwx------  5 65534 65534 4096 Feb  3 14:20 .
drwxr-xr-x 12 65534 65534 4096 Feb  3 14:20 ..

Meaning: UID/GID 65534 is typically “nobody/nogroup.” Your client and server disagree about identity mapping.

Decision: Fix NFS idmapping (same UID/GID across systems, or proper idmapd configuration, or use NFSv4 with consistent identities).

Task 15: Check immutable attribute (the “why won’t chmod/chown work?” culprit)

cr0x@server:~$ lsattr -d /mnt/oldhome/cr0x/Documents
-------------e------- /mnt/oldhome/cr0x/Documents

Meaning: No i flag, so it’s not immutable. If you saw ----i--------, modifications would be blocked even as root.

Decision: If immutable, remove it with chattr -i (carefully, and only where justified).

Task 16: Check SELinux denials (when everything looks right but still fails)

cr0x@server:~$ getenforce
Enforcing

cr0x@server:~$ sudo ausearch -m avc -ts recent | tail -n 3
type=AVC msg=audit(1707041254.332:812): avc:  denied  { write } for  pid=2419 comm="vim" name="report.txt" dev="sdb2" ino=931281 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_t:s0 tclass=file permissive=0

Meaning: SELinux is denying writes based on labels (tcontext), not Unix permissions.

Decision: Restore proper contexts (often restorecon) instead of weakening Unix permissions.

Ownership fixes that won’t set your system on fire

The correct fix depends on where the files live and how they were created. But the golden rule is consistent: fix identity, don’t wallpaper over it.

The best-case scenario: local Linux filesystem (ext4/xfs/btrfs)

If your files are on a standard Linux filesystem, and your user got a new UID after reinstall, you have two clean options:

1. Change the user’s UID/GID back to match the files (useful if you have many files and want to keep numeric ownership stable).
2. Change file ownership to match the new UID/GID (useful if the new system’s UID assignments matter or you have multiple users).

I prefer option 2 for single-user desktops and laptops. I prefer option 1 for servers with shared storage, NFS exports, or anything that cares about stable identity across hosts.

Fix files (chown) vs fix the account (usermod)

Option A: Change ownership of an old home directory

You already saw the safest pattern: chown -R --from=OLDUID:OLDGID NEWUID:NEWGID. It’s boring and correct. Which is a compliment.

Be surgical:

• Use -xdev with find to avoid crossing into mounted subtrees.
• Do a preview (find ... -uid OLDUID) before you mutate anything.
• Don’t run recursive chown on /. That way lies madness.

Option B: Make your new user match the old UID/GID

This can be cleaner when the old disk is authoritative and you want continuity across reinstalls.

cr0x@server:~$ id cr0x
uid=1000(cr0x) gid=1000(cr0x) groups=1000(cr0x),27(sudo)

cr0x@server:~$ sudo usermod -u 1001 cr0x
cr0x@server:~$ sudo groupmod -g 1001 cr0x

Meaning: You changed the account’s numeric identity. Existing files owned by 1000 may now be “orphaned” and need a follow-up chown from 1000 to 1001.

Decision: Only do this if 1001 is free and you understand the blast radius (services, cron jobs, containers, system users). It’s stable, but it’s not casual.

Operational advice: If this is a multi-user system, coordinate UID/GID allocation. On fleets, use centralized identity (LDAP/FreeIPA/AD) or a strict UID policy. Ad-hoc local users are how you get “it worked on the old server” as a lifestyle.

When chmod is the wrong tool (most of the time here)

chmod changes the mode bits. It does not change ownership. If you’re seeing files owned by UID 1001 and you’re UID 1000, chmod can’t grant you ownership. It can grant group/other access, which is sometimes acceptable for shared data but is usually a security regression for personal home directories.

Use chmod for what it’s good at:

• Fixing broken directory modes (missing execute bit on directories).
• Normalizing .ssh modes.
• Making team directories setgid for predictable group ownership.

Use chown to fix “who you are.”

Special cases: ACLs, NFS, Samba, FAT/NTFS, ZFS, containers

POSIX ACLs: the invisible layer that can override your expectations

ACLs add per-user and per-group entries beyond the classic owner/group/other triplet. They also introduce a mask that can silently reduce effective permissions.

Typical post-reinstall pain:

• You chown everything correctly. Still can’t write. ACL denies or mask restricts.
• New files created in a directory inherit default ACLs you forgot existed.

Diagnosis is simple: getfacl. Fixing depends on intent:

• If ACLs were accidental baggage: remove them with setfacl -b (and maybe clear defaults with setfacl -k).
• If ACLs are deliberate (shared directory): adjust entries and mask properly.

NFS: identity must match on both sides

NFS doesn’t magically make “cr0x” mean the same thing everywhere. Classic NFSv3 is mostly numeric. NFSv4 can use names with idmapping, but misconfigurations are common, especially after a reinstall where /etc/idmapd.conf defaults differ.

Clues you’re in NFS land:

• Files show UID/GID 65534 (“nobody”).
• Root can’t chown due to server-side restrictions.
• Permissions vary depending on which host you’re on.

Fix strategy:

• Prefer consistent UID/GID allocation across hosts (central identity or strict local policy).
• Verify NFS export options and whether root squashing is in play.
• Don’t “fix” by chmod 777 on shared exports. That just spreads the problem.

Samba/CIFS: your Linux UID is not the boss here

With SMB shares, access is largely determined by server-side ACLs and authentication. Client-side mount options can map ownership for display and local permission checks, but they won’t rewrite the server’s idea of who can do what.

Implication: if you can’t access files on a Samba share after reinstall, don’t start with chown. Start with:

• Credentials and domain membership
• Server-side ACL inheritance
• Mount options (uid, gid, nounix, mfsymlinks, etc.)

FAT/NTFS: permissions are mostly cosplay

FAT has no Unix ownership. NTFS has Windows ACLs; Linux drivers can map them, but many setups use a simplified permission model.

Symptoms:

• chown returns “Operation not permitted” or appears to work but doesn’t stick.
• Everything shows owned by the mount UID/GID.

Fix strategy:

• Set ownership via mount options (e.g., uid=1000,gid=1000).
• Choose appropriate umask, fmask, dmask.
• If you need real Unix semantics, copy data onto ext4/xfs/btrfs.

ZFS: dataset properties can make you think you’re crazy

ZFS stores Unix ownership normally, but it also has dataset properties that affect behavior—especially if you’re mixing Linux hosts, containers, and different ACL modes. ACLtype and xattr storage settings can change how permissions behave and how tools report them.

For ZFS, treat it like a real production filesystem (because it is):

• Verify dataset mountpoints and that you’re fixing the right path.
• Check ACL mode if you’re seeing confusing results.
• Don’t recursively chown across datasets unless you meant to.

Containers and user namespaces: UID 1000 inside is not UID 1000 outside

Reinstall + containers is where people lose afternoons. With user namespaces, a container’s UID 0 can map to a non-zero host UID range. Your files can appear “owned by 100000” or similar on the host. That’s not corruption; it’s mapping.

Decision point:

• If you want host and container to share writable directories, design the mapping intentionally.
• Don’t blindly chown host paths to “fix” container permissions; you might break the mapping and reduce security.

Joke #1: Containers are great until you discover your file is owned by “100000” and you start bargaining with the kernel like it’s a sentient being.

Three corporate mini-stories from the trenches

Mini-story 1: The incident caused by a wrong assumption

A company had a small fleet of build agents. Nothing exotic: Linux VMs, each with a local SSD for workspace and an NFS mount for caching build artifacts. A routine image refresh happened after a security patch cycle. New OS, new base image, same hostnames. Everyone assumed the user account would be “the same.”

It wasn’t. The automation created the build user after a couple of system accounts and landed it on a different UID than before. Locally, it didn’t matter much—fresh workspace, fresh files. On NFS, it mattered immediately. The cache directory was owned by the old UID. The build user suddenly couldn’t write artifacts, so jobs started failing in a way that looked like random compiler errors and timeouts. The CI system’s logs were full of noise and almost no “permission denied” messages because the build tooling retried, fell back, and then failed later.

The initial response was predictable: “maybe NFS is flaky.” Someone restarted the NFS client service. Someone else remounted the share. That bought minutes at best. The failure was identity drift, not network.

The fix was simple and slightly humiliating: enforce a consistent UID for the build user across images, and chown the NFS cache directory to that UID/GID. The lesson was more valuable than the outage: if a resource is shared across hosts, numeric identity must be treated as an API, not a coincidence.

Mini-story 2: The optimization that backfired

A different org tried to speed up workstation re-provisioning. They stopped copying home directories and instead moved them onto a secondary disk that would survive OS reinstalls. “We’ll just mount it at /home after reinstall. Easy.”

It was easy—for the first few laptops. Then a new OS release changed user creation behavior, and the first created user now reliably grabbed UID 1000, even when IT wanted a different naming scheme. Some laptops ended up with the old home directory owned by UID 1005, new user at UID 1000, and a desktop environment that handled the mismatch by failing in creative ways. Login loops. Broken keyrings. Applications unable to create config files. People lost half a day each, and the helpdesk developed a twitch.

They “optimized” by skipping a data migration step, but they also skipped the part where you define how identity persists across time. The actual fix was to bake a predictable UID/GID assignment into provisioning (or use centralized identity), and to add a post-install ownership reconciliation step that was explicit and audited. The revised process took an extra few minutes per machine. It saved hours of chaos.

Joke #2: Nothing is faster than skipping steps—until you measure total time spent unskipping them later.

Mini-story 3: The boring but correct practice that saved the day

A finance-ish company (the kind that loves audit trails) ran a mixed environment: some bare metal, some VMs, and a couple of big file servers. They had a simple, boring rule: all human users came from a central directory, and local user creation on servers was discouraged unless justified. UID/GID allocation was consistent across every Linux system.

One weekend, they had to reinstall a host that acted as a data processing node. It had local scratch space and mounted shared datasets. The reinstall went smoothly, and the node rejoined the cluster without drama. No permission errors. No emergency chown. No mystery “nobody” ownership. The operator who did the work slept normally that night, which in this profession counts as a win.

The reason wasn’t heroism. It was policy. The host rejoined the directory service, pulled the same numeric identities, and the shared storage behaved the same way as before. Their change management looked painfully conservative in normal times. Under stress, it paid out like insurance.

The practical takeaway: if you operate more than one machine, stable identity is operational hygiene. It’s not bureaucracy; it’s what prevents a reinstall from turning into a permissions crime scene.

Common mistakes (symptom → root cause → fix)

1) “chmod 777 didn’t fix it”

Symptom: You ran chmod -R 777 and still can’t write, or some apps still fail.

Root cause: Ownership mismatch (UID/GID), read-only mount, ACL deny, immutable bit, or SELinux/AppArmor denial.

Fix: Check numeric ownership with ls -ln, mount mode with findmnt, ACLs with getfacl, attributes with lsattr, and SELinux with ausearch. Then use chown or correct the mount/security layer.

2) “chown: Operation not permitted” on your external drive

Symptom: chown fails on a mounted drive.

Root cause: Filesystem doesn’t support Unix ownership semantics (FAT), or you’re on CIFS/NTFS with restricted mapping.

Fix: Use mount options (uid=, gid=, dmask=, fmask=), or copy data to a Linux-native filesystem if you need real owners.

3) “Everything is owned by nobody:nogroup” on NFS

Symptom: UID/GID shows 65534; access fails.

Root cause: NFS identity mapping mismatch (client and server disagree), or missing/incorrect idmap configuration.

Fix: Ensure consistent UID/GID across systems (central directory helps), validate NFSv4 idmapping domain, and re-mount after changes.

4) “I can read but not write; I own the file”

Symptom: Owner looks right, mode bits suggest write, still denied.

Root cause: ACL mask restricts, filesystem is read-only, immutable attribute set, or SELinux denies.

Fix: getfacl for mask, findmnt for ro, lsattr for i, and check SELinux/AppArmor logs.

5) “After fixing ownership, SSH keys stopped working”

Symptom: SSH login fails with permission-related messages.

Root cause: .ssh directory or key files became too permissive (group-writable), or wrong ownership remained.

Fix: Ensure ~/.ssh is 0700, private keys 0600, and ownership matches the user.

6) “My desktop session is stuck in a login loop”

Symptom: You log in, screen flashes, you’re back at login.

Root cause: Home directory not writable for session files (ownership mismatch), or .Xauthority/.ICEauthority owned by the wrong UID.

Fix: Fix ownership of the home directory, then remove/recreate the authority files if needed.

7) “I fixed /home, but some subdirectory still denies access”

Symptom: Most things work; one project directory doesn’t.

Root cause: Another UID/GID owns that subtree, or it’s a mount point to elsewhere, or it has restrictive ACLs.

Fix: Use find ... -xdev to avoid crossing mounts, and inspect the specific directory with ls -ldn and getfacl.

Checklists / step-by-step plan

Plan A: You reinstalled Linux and mounted your old ext4 home directory

1. Identify your current UID/GID: id.
2. Identify old ownership: ls -ldn /mnt/oldhome/you.
3. Confirm filesystem supports ownership: findmnt -no FSTYPE,OPTIONS /mnt/oldhome.
4. Preview scope: sudo find /mnt/oldhome/you -xdev -uid OLDUID | head.
5. Change ownership with a seatbelt: sudo chown -R --from=OLDUID:OLDGID NEWUID:NEWGID /mnt/oldhome/you.
6. Re-test writes: touch a temp file.
7. Validate sensitive perms: normalize .ssh.
8. Check ACLs if weirdness remains: getfacl.

Plan B: Shared storage or multiple hosts (NFS/cluster)

1. Stop and decide: do you want stable UID/GID across hosts? You do. Act like it.
2. Pick an authoritative UID/GID for each human/service account.
3. Make identities consistent (directory service, or enforce local allocation policy).
4. Fix ownership on the server side where appropriate (especially for NFS exports).
5. Verify from a client: ls -ln should show the expected numeric owners.
6. Lock it in: add checks in provisioning to confirm UID/GID before mounting shared paths.

Plan C: External drive formatted as NTFS/FAT

1. Confirm filesystem type: findmnt -no FSTYPE,OPTIONS /mnt/drive.
2. Don’t fight chown: assume it won’t persist.
3. Set mount mapping: choose uid, gid, masks that match your needs.
4. If you need Unix semantics: copy data onto ext4/xfs/btrfs and work there.

Interesting facts and historical context

• UID/GID are stored as numbers on disk because early Unix systems needed compact, fast permission checks without string lookups.
• Classic Unix used 16-bit UIDs in early implementations; modern systems support far larger ranges, but legacy assumptions still show up in tooling.
• The “nobody” user is a convention used to map unknown or untrusted identities (commonly UID 65534), especially in NFS contexts.
• POSIX ACLs were added to solve real multi-user problems where the owner/group/other model wasn’t expressive enough for shared directories.
• Setgid on directories is an old-school collaboration trick that still works: new files inherit the directory’s group, reducing “why is this group wrong?” incidents.
• NFSv4 introduced stronger identity semantics and stateful operation compared to NFSv3, but misconfigured idmapping can be worse than simple numeric-only behavior.
• FAT predates Unix permissions and doesn’t have a concept of per-file owners; Linux has to project a permission model on top of it.
• SELinux came out of security research and enterprise needs to enforce mandatory access controls beyond discretionary Unix permissions, which is why it can override your “correct” chmod/chown.
• User namespaces changed the game by allowing containers to remap UIDs, improving isolation but making file ownership look bizarre on the host.

FAQ

1) Why did reinstalling change file access if my username is the same?

Because the filesystem stores numeric UID/GID, not the username. After reinstall, the username can map to a different UID/GID, so the kernel treats you as a different owner.

2) Should I fix this by changing my new user’s UID or by chowning files?

If this is a single machine with local storage, chowning the files to the new UID is usually simplest. If storage is shared across machines, keeping stable UIDs (and changing the account to match) is often safer.

3) Why does chmod not solve “Permission denied” in my case?

Because you’re not the owner (numerically). chmod changes mode bits, but it doesn’t change ownership. Also, ACLs/SELinux/read-only mounts can still block you.

4) What’s the safest way to do a recursive ownership fix?

Use chown -R --from=OLDUID:OLDGID NEWUID:NEWGID on the specific directory, and preview with find -uid OLDUID. Add -xdev to avoid crossing mount points when using find.

5) I ran chown -R and now something is broken. What did I likely hit?

Common casualties: mounted subdirectories (you changed ownership of another filesystem), application directories expecting specific service accounts, and SSH key permissions. Check for mount points and re-verify service users.

6) My files are on an NTFS drive. Can I permanently fix ownership?

Not in the Unix sense. You typically map ownership via mount options. If you need per-file Unix ownership and modes, move the data to a Linux-native filesystem.

7) Why do my files show as owned by “nobody” on NFS?

Identity mapping failed between client and server, or the UID/GID is unknown on one side. Fix by making identities consistent or correcting NFS idmapping configuration.

8) I own the directory, but I still can’t write. What else blocks writes?

Read-only mounts, ACL mask restrictions, immutable attributes, SELinux/AppArmor policy, or quota limits. Diagnose with findmnt, getfacl, lsattr, and security logs.

9) Can I avoid this entirely next time?

Yes: keep UIDs stable (central identity or provisioning policy), document UID/GID allocations for service accounts, and test mounts and ownership after rebuilds before you hand the system back to humans.

Conclusion: next steps you can do today

If you’re seeing “Access denied” on your own files after a reinstall, stop treating it like a permissions mystery. It’s usually identity drift. Numbers changed. The kernel is doing exactly what it’s told.

Do this next:

1. Run id and ls -ln on a failing path. Confirm the UID/GID mismatch.
2. Confirm filesystem type and mount flags with findmnt. Rule out read-only and “ownership is faked” mounts.
3. Fix ownership with chown -R --from=OLDUID:OLDGID NEWUID:NEWGID on the smallest subtree that makes sense.
4. If the problem persists, check ACLs and SELinux/AppArmor before you start “chmod therapy.”
5. For shared environments, make UID/GID consistency a policy, not a hope.

Once you’ve done this a few times, you’ll start to recognize the smell of it within seconds: same username, wrong numbers, and a filesystem that politely refuses to participate in your nostalgia.