Ubuntu server

/dev/sda: clean. files. blocks

sudo apt-get purge nvidia*

sudo ubuntu-drivers autoinstall

Automount a device

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

Automount vmware shared folder

sudo nano /etc/fstab

vmhgfs-fuse /media/disk/vmshared fuse defaults,allow_other 0 0 

Mount a device

Locate the device with lsblk

lsblk

cd /media/disk

mkdir hdd01

mount -t ntfs /dev/INSERTDISKNAMEHERE1 /media/disk/hdd01

Mount LDM data partition

sudo apt install testdisk

testdisk

Delete Disk partitions and add new

Locate the device with lsblk

sudo fdisk /dev/INSERTDISKNAMEHERE

d

w

n

CTRL + C

mkfs.ext4 /dev/INSERTDISKNAMEHERE1

Unmount a device

umount /dev/INSERTDISKNAMEHERE1

Format Disk to ext4

Locate the device with lsblk

lsblk

sudo mkfs -t ext4 /dev/INSERTDISKNAMEHERE1

Automatic login as root with passwd for SSH

sudo su

passwd

Sign a message with PGP Encryption

sudo apt install gnupg

sudo apt install gnupg

Remove ipv4 address

ip addr show INSERTNETWORKCARDNAME

sudo ip addr del 192.168.1.123/24 dev INSERTNETWORKCARDNAME

DNS Errors

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 timeout
• DNS servers 1.1.1.1 and 1.0.0.1 not responding when queried via dig.

Troubleshooting Steps

1. Check DNS Configuration:

   • Verify the current DNS configuration using:

     resolvectl status
     

   • Ensure the correct DNS servers (e.g., 1.1.1.1 and 1.0.0.1) are set under the correct network interface.

2. Test Network Connectivity:

   • Confirm that you can ping external DNS servers:

     ping 1.1.1.1
     

   • If ping to 1.1.1.1 works but DNS queries fail, continue to the next step.

3. Flush DNS Cache:

   • If using systemd-resolved, flush the DNS cache:

     sudo systemd-resolve --flush-caches
     

   • Check the DNS resolution again using:

     dig google.com
     

4. Restart Network Services:

   • Restart the DNS resolver:

     sudo systemctl restart systemd-resolved
     

5. Router Issues:

   • If the issue persists, try restarting your router. This can refresh network configurations and solve connection issues.

6. Resolution:

   • In this case, restarting the router resolved the DNS timeout issue.

General server crashes/freezes

dmesg | grep -iE "error|fail|critical|warn"

sudo journalctl --since "24 hours ago" > all_logs_last_24_hours.txt

Failed to allocate directory watch: Too many open files

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

VSCODE-Server HIGH CPU/Memory on SSH

Avoid Accessing / with VS Code on Root User (Remote SSH)

Opening the entire filesystem at / results in:

• High Memory Usage: VS Code starts indexing all system directories, including large folders like /usr, /var, and /lib. This can cause memory consumption to spike, especially on resource-constrained servers, eventually leading to crashes or system slowdowns.
• Excessive CPU Load: The process of scanning and indexing all files takes a toll on CPU resources, impacting server performance.
• Increased Risk of Crashes: Memory-intensive operations may cause node processes (e.g., when running npm) to crash due to out-of-memory errors, especially when working on projects or using large package managers like npm or yarn.

Recommendation

• Avoid Opening /: Instead, limit your workspace to the project directory or a specific path that contains the files you need.
• Avoid Using Root User: Use a non-root user with appropriate privileges to minimize the risk of accidental changes to system files and to reduce the impact of potential misconfigurations or crashes.

Does htop or btop still show high CPU on program: rg? with command .vscode-server?

1. Open Visual Studio Code
2. Go to: File --> Preferences --> Settings
3. Search for: search.followsymlinks
4. Disable the following setting: Search: Follow Symlinks - Controls whether to follow symlinks while searching.

Running .sh scripts

bad interpreter: No such file or directory

/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.

Failed to allocate directory watch (Too many open files)

Overview

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

Common Symptoms

• Running 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.
• Node.js builds (like Nuxt) crash during file watching or hot-reloading.
• Docker containers get stuck in crash loops.

The Root Cause

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:

1. Watches (max_user_watches): How many individual files/directories can be monitored. (Usually defaults to a high number).
2. Instances (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.

Diagnosis

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.

The Solution

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.

1. Apply the Limits

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

2. Reload the Kernel Parameters

Apply the changes immediately without needing to reboot the server:

sudo sysctl -p

3. Cleanup & Verification

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 available inotify resources.