sudo apt-get purge nvidia*
sudo ubuntu-drivers autoinstall
Locate the device with lsblk -f and save the UUID
lsblk -f
sudo nano /etc/fstab
#PARTITIONLABLEHERE (dev/PARTITIONNAMEHERE)
UUID=INSERTUUIDHERE /media/disk/hdd01 ext4 defaults 0 0
| Filesystem Type | Description | Supported Platforms | Use Case |
|---|---|---|---|
ext4 |
Fourth extended filesystem, a widely used filesystem for Linux, providing journaling and large volume support. | Linux | Best for Linux OS installations and general use on native Linux disks. |
ext3 |
Older version of ext4 with less performance and features but still stable. | Linux | Older Linux systems, though less efficient compared to ext4. |
ext2 |
Lacks journaling, making it faster but less safe during crashes. | Linux | Suitable for small partitions like /boot or USB drives where journaling isn’t necessary. |
xfs |
High-performance journaling filesystem, commonly used in large-scale enterprise systems. | Linux | Suitable for large file systems, high-performance storage, and server applications. |
btrfs |
Advanced filesystem with features like snapshots and built-in RAID support. | Linux | Great for advanced use cases like versioning, snapshots, and RAID. |
ntfs-3g |
Userspace driver to mount NTFS with full read/write support on Linux. | Linux, Windows | For full read/write support of NTFS filesystems on Linux. |
ntfs |
Default Windows filesystem; supports large files and partitions but with limited write support on Linux. | Windows, Linux (read-only by default) | Use for dual-boot systems or external drives shared between Windows and Linux (with ntfs-3g). |
fat32 |
Older filesystem with wide compatibility but limited to 4GB file size. | Linux, Windows, macOS | Best for USB drives and external storage with maximum compatibility across platforms. |
exfat |
Supports larger file sizes than FAT32 and has broad compatibility. | Linux, Windows, macOS | Preferred for external storage (USB, SD cards) shared between multiple OSes. |
vfat |
Another name for FAT32, commonly used when mounting FAT32 on Linux systems. | Linux, Windows, macOS | Similar to FAT32, used mainly for older external drives or small partitions. |
hfs+ |
Apple’s older hierarchical filesystem, used before APFS. | Linux, macOS | Suitable for legacy macOS systems; use hfsplus for mounting on Linux. |
zfs |
Advanced filesystem and volume manager known for data integrity, snapshots, and high scalability. | Linux, FreeBSD, Solaris | Great for large-scale storage, particularly where data integrity is critical. |
iso9660 |
Filesystem standard for optical disc media like CDs/DVDs. | Linux, Windows, macOS | Used for mounting CDs, DVDs, or ISO image files. |
sudo nano /etc/fstab
vmhgfs-fuse /media/disk/vmshared fuse defaults,allow_other 0 0
Locate the device with lsblk
lsblk
cd /media/disk
mkdir hdd01
mount -t ntfs /dev/INSERTDISKNAMEHERE1 /media/disk/hdd01
sudo apt install testdisk
testdisk
Locate the device with lsblk
sudo fdisk /dev/INSERTDISKNAMEHERE
d
w
n
CTRL + C
mkfs.ext4 /dev/INSERTDISKNAMEHERE1
umount /dev/INSERTDISKNAMEHERE1
Locate the device with lsblk
lsblk
sudo mkfs -t ext4 /dev/INSERTDISKNAMEHERE1
sudo su
passwd
sudo apt install gnupg
sudo apt install gnupg
ip addr show INSERTNETWORKCARDNAME
sudo ip addr del 192.168.1.123/24 dev INSERTNETWORKCARDNAME
Able to ping local IPv4 addresses but unable to ping external DNS (e.g., 1.1.1.1 or 1.0.0.1), and DNS resolution failures with error messages such as:
dial tcp: lookup registry-1.docker.io on 127.0.0.53:53: read udp 127.0.0.1:39511->127.0.0.53:53: i/o timeout1.1.1.1 and 1.0.0.1 not responding when queried via dig.Check DNS Configuration:
resolvectl status
1.1.1.1 and 1.0.0.1) are set under the correct network interface.Test Network Connectivity:
ping 1.1.1.1
1.1.1.1 works but DNS queries fail, continue to the next step.Flush DNS Cache:
systemd-resolved, flush the DNS cache:sudo systemd-resolve --flush-caches
dig google.com
Restart Network Services:
sudo systemctl restart systemd-resolved
Router Issues:
Resolution:
dmesg | grep -iE "error|fail|critical|warn"
sudo journalctl --since "24 hours ago" > all_logs_last_24_hours.txt
echo "fs.inotify.max_user_instances=1280" | sudo tee -a /etc/sysctl.conf
echo "fs.inotify.max_user_watches=655360" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p
Avoid Accessing
/with VS Code on Root User (Remote SSH)
Opening the entire filesystem at / results in:
/usr, /var, and /lib. This can cause memory consumption to spike, especially on resource-constrained servers, eventually leading to crashes or system slowdowns./: Instead, limit your workspace to the project directory or a specific path that contains the files you need.Does htop or btop still show high CPU on program: rg? with command .vscode-server?
search.followsymlinks/bin/bash^M: bad interpreter: No such file or directory
Windows ends every line with two invisible characters: Carriage Return + Line Feed (\r\n).
Linux ends every line with just one: Line Feed (\n).
Run the following command to remove the invisible Windows characters:
sed -i 's/\r$//' your_script_name.sh
Here is a complete Wiki.js Markdown article you can copy and paste directly into your Ubuntu Troubleshooting section.
When running a high number of Docker containers (80+) or running heavy filesystem-monitoring workloads like Node.js (Nuxt), GitLab, or Docker/containerd, you may encounter the following error across various system services:
Failed to allocate directory watch: Too many open files
apt update fails with the error above.systemd or systemd-networkd starts looping and spamming the journal logs with Failed to allocate manager object: Too many open files.Despite the error saying "Too many open files", the issue is usually not the global file descriptor limit. Instead, the system has exhausted its inotify instances.
Linux uses inotify to monitor files and directories for changes. There are two limits at play:
max_user_watches): How many individual files/directories can be monitored. (Usually defaults to a high number).max_user_instances): How many separate "monitoring buckets" can be created. (Ubuntu defaults to 128).When running many Docker containers, GitLab microservices, and Node.js watchers (like chokidar), the default 128 instances are quickly exhausted. Once the system runs out of instances, it throws the EMFILE (Too many open files) error.
You can check your current inotify limits by running:
sysctl fs.inotify.max_user_instances
sysctl fs.inotify.max_user_watches
If your max_user_instances is set to 128, it is highly likely the cause of the bottleneck.
To fix this, we need to permanently increase the inotify instance limits in the kernel parameters. This uses a microscopic amount of RAM and is considered best practice for Docker hosts and CI/CD runners.
Run the following commands to append the new, higher limits to your /etc/sysctl.conf file:
# Increase the maximum number of inotify instances
echo "fs.inotify.max_user_instances=8192" | sudo tee -a /etc/sysctl.conf
# Increase the max user watches slightly (optional but recommended for Node.js workloads)
echo "fs.inotify.max_user_watches=524288" | sudo tee -a /etc/sysctl.conf
Apply the changes immediately without needing to reboot the server:
sudo sysctl -p
Because system processes like systemd may have crashed or throttled while the limit was exhausted, it is recommended to reload the systemd daemon:
sudo systemctl daemon-reexec
Finally, verify the fix by running the command that initially failed:
sudo apt update
Tip: If any specific Docker containers are still acting up after applying the fix, simply restart them (
docker restart <container_name>) or restart the Docker daemon (sudo systemctl restart docker) to allow them to boot with the newly availableinotifyresources.