[Arch Linux] [Manjaro] How to avoid "Visual Studio Code is unable to watch for file changes in this large workspace" (error ENOSPC)

inotify-instructions.md

To avoid this error, we need to increase the inotify watcher limit.

The way to do this is different on Arch based distributions than other Linux distributions.

Instructions for Arch Linux/Manjaro

Check for an already existing inotify config file (recent versions of Manjaro include one)

ls /etc/sysctl.d/*-max_user_watches.conf

a) If no output

echo fs.inotify.max_user_watches=524288 | sudo tee /etc/sysctl.d/40-max_user_watches.conf && sudo sysctl --system

b) If the command outputs a file

(in the rare case where it outputs multiple files, continue using the last one in the list)

# replace `/etc/sysctl.d/50-max_user_watches.conf` with the file returned from the previous `ls` command
echo fs.inotify.max_user_watches=524288 | sudo tee /etc/sysctl.d/50-max_user_watches.conf && sudo sysctl --system

Check it's working

cat /proc/sys/fs/inotify/max_user_watches

Expected output: 524288

Credits

• inotify og dev
• explanation and troubleshooting
• manjaro fix original

Worked here on Manjaro but I needed to delete the files with typo

How to make this change when on linux not running as root user.
I'm connecting to remote development environment using Remote-SSH extension

How to make this change when on linux not running as root user. I'm connecting to remote development environment using Remote-SSH extension

Pretty sure you need privileged access, kernel changes generally require root, unless you have a really permissive system.

Works

It works perfect

so what causes this? only thing I've changed is to add optimizations to my Ubuntu Desktop hyperv guest recommended by Qwen:

#/dev/disk/by-uuid/07a3559e-623xxxxxxxb-06179c00c39b / ext4 defaults,noatime,nobarrier,commit=60 0 1
dev/disk/by-uuid/07a3559e-623xxxxxxxxxx6179c00c39b / ext4 noatime,nobarrier,commit=60,errors=remount-ro 0 1

Any chance that could affect it?

thx for the fix btw!

so what causes this? only thing I've changed is to add optimisationṡ to my Ubuntu Desktop hyperv guest recommended by Qwen:

#/dev/disk/by-uuid/07a3559e-623xxxxxxxb-06179c00c39b / ext4 defaults,noatime,nobarrier,commit=60 0 1
dev/disk/by-uuid/07a3559e-623xxxxxxxxxx6179c00c39b / ext4 noatime,nobarrier,commit=60,errors=remount-ro 0 1

Any chance that could affect it?

thx for the fix btw!

I think your problem is unlikely to have anything to do with this particular situation. Presumably the qwen info it gave you was slightly incorrect

OK thanks for the reply. The two events were associated by temporal locality. I received the notification from VS Code ~30 s after applying the fstab change & remount. Thus my human brain decided that the two events were associated in a causal relationship.

I think your problem is unlikely to have anything to do with this particular situation. Presumably the qwen info it gave you was slightly incorrect

Not surprised- I ended up reverting the "optimizations" to fstab not very long after I made them. The volume in question (mounted as /) is a RAID 10 of 4 x Samsung 970 Evo SSDs. Which is what prompted her to recommend those settings.