The day my Downloads folder vanished after a simple umask change: my recovery steps

 Posted on 9 September 2026  |  5 minutes  |  954 words  |  Tom

When a simple umask change turned my Downloads folder into a ghost

I was tweaking my user profile in the middle of a busy afternoon, trying to tighten up file permissions for a fresh install of Arch Linux. I had just set umask 027 in my ~/.bashrc to make new files group‑readable but not world‑readable. A few minutes later I opened my file manager, clicked on Downloads, and the folder was gone. No error, no warning—just an empty directory listing. The rest of my home directory looked fine, but the Downloads folder was missing, and all the files I had just downloaded were nowhere to be seen.

Below is a step‑by‑step walk‑through of how I diagnosed the problem, what I learned about umask and filesystem permissions, and how I recovered the lost data. The same techniques apply to any situation where a directory disappears after a permission change or a mis‑configured umask.

1. The first clues: ls -l and stat

The first thing I did was list the contents of my home directory:

$ ls -ld ~
drwxr-xr-x  3 user user 4096 Sep  9 10:12 /home/user

The home directory itself had the expected drwxr-xr-x permissions. Next, I checked the Downloads directory:

$ ls -ld ~/Downloads
ls: cannot access '/home/user/Downloads': No such file or directory

The error confirmed that the directory was truly missing, not just hidden. I also ran stat on the parent directory to see if there were any hidden attributes:

$ stat ~/Downloads
stat: cannot stat '/home/user/Downloads': No such file or directory

No luck. The next step was to look for the directory in the filesystem’s inode table.

2. Why a umask change could delete a directory

umask controls the default permissions for newly created files and directories. The value 027 means:

Permission Symbol Binary Resulting mode
Owner rwx 111 7
Group r-x 101 5
Others — 000 0

When a new directory is created, the kernel subtracts the umask from 0777. So a umask 027 yields 0750 for directories. That is fine for most cases, but the problem arose because the Downloads folder already existed and had a different permission set. When I set the umask in ~/.bashrc, the shell started applying it to every subsequent command, including mkdir and cp. If I had accidentally run mkdir ~/Downloads again, the new directory would have been created with 0750. The original Downloads directory, which was 0755, would have been overwritten by the new one, effectively erasing the old contents.

In this case, I didn’t run mkdir explicitly, but I had a background script that automatically created a fresh Downloads folder when a new session started. The script ran with the new umask, creating a brand‑new directory and dropping the old one.

3. Checking the filesystem for remnants

3.1. find with -inum

Every file and directory has an inode number. If the old Downloads directory had been deleted but its inode was still present, I could find it:

$ find /home/user -inum <old_inode>

To get the inode number of the missing directory, I used stat on a file that was still inside it (I remembered a PDF I’d downloaded a week ago):

$ stat ~/Downloads/oldfile.pdf
  File: ‘/home/user/Downloads/oldfile.pdf’
  Size: 123456   Blocks: 256   IO Block: 4096 regular file
Device: 803h/2051d   Inode: 12345678     Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/user)   Gid: ( 1000/user)

The inode number 12345678 belonged to the file, not the directory. I used find to locate the directory inode:

$ find /home/user -inum 12345678 -printf '%p\n'

No output meant the inode had been reclaimed by the filesystem. The directory was gone for good from the filesystem’s point of view.

3.2. lsof and fuser

I wanted to see if any process still had the old directory open:

$ lsof | grep Downloads

No matches. The directory was not in use.

4. Looking for a backup or snapshot

4.1. Trash

The first place I checked was the Trash. Many desktop environments automatically move deleted files to ~/.local/share/Trash. I opened the Trash folder and found the entire Downloads directory there, along with all its contents.

$ ls -l ~/.local/share/Trash/files/Downloads

The directory was intact, but it was a copy of the old state, not the live one. Restoring from Trash was the quickest fix:

$ mv ~/.local/share/Trash/files/Downloads ~/Downloads

After moving it back, the directory reappeared with all files in place. I verified the permissions:

$ ls -ld ~/Downloads
drwxr-xr-x  2 user user 4096 Sep  9 10:12 /home/user/Downloads

The permissions were back to 0755, matching the original state.

4.2. System snapshots

If I had a snapshot system in place—such as Btrfs subvolume snapshots or LVM snapshots—I could have rolled back the entire home directory. I checked for Btrfs snapshots:

$ sudo btrfs subvolume list /home
ID 256 gen 12345 top level 5 path @
ID 257 gen 12344 top level 5 path @snapshot-2026-09-08

The snapshot @snapshot-2026-09-08 existed. I could mount it temporarily and copy the Downloads folder back:

$ sudo mount -o subvol=@snapshot-2026-09-08 /home /mnt/snap
$ cp -a /mnt/snap/Downloads ~/Downloads
$ sudo umount /mnt/snap

This approach is useful when Trash is not available or when you need to recover a larger set of files.

5. Re‑creating the directory safely

If I had not found the folder in Trash or a snapshot, I would have had to recreate it. The key is to preserve the original ownership and permissions. I used mkdir with the -m flag to set permissions explicitly:

$ mkdir -m 0755 ~/Downloads

Then I restored the ownership:

$ chown user:user ~/Downloads

If I had a backup of the directory’s contents (e.g., from a cloud sync or external drive), I could copy them back:

$ rsync -a /backup/Downloads/ ~/Downloads/

6. Preventing accidental deletions

6.1. Use a more conservative umask

A umask of 027 is fine for most

linux  open-source 

See also