Hello Engineers, I'm currently testing a self-hosted file-sharing solution, Syncthing. Below is a list of options that help achieve a reasonably secure configuration. I haven't described these options in detail, all of them can be found in the documentation. Settings -> General -> Device name -> Fill in the device name Settings -> General -> Anonymous Usage Reporting -> Disable Settings -> GUI -> Start Browser -> Disable Advanced -> GUI -> Address -> Fill in the local network interface ip address Advanced -> GUI -> Enabled -> Leave Enabled Advanced -> GUI -> Password -> Fill in (password to log in to the GUI) Advanced -> GUI -> Use TLS -> Enable Advanced -> GUI -> User -> Fill in a user name (user to log in to the GUI) Advanced -> Options -> Always Local Nets -> Fill in a local network interface Advanced -> Options -> Announce LAN Address -> Disable Advanced -> Options -> Crash reporting Enabled -> Disable Advanced -> Options -> Global Announce Enabled -> Disable Advanced -> Options -> Nat Enabled -> Disable Advanced -> Options -> Relays Enabled -> Disable Advanced -> Options -> Local Announce enabled -> Enabled by default, should be enabled only if local address explicitly specified by the option "Always Local Nets" Advanced -> Options -> Overwrite Remote Device Names On -> Enable Advanced -> Options -> Listen Address -> Left default

When I spin up a new Ubuntu VM on Proxmox, I like to keep the setup minimal but fully functional. My goal is always the same: get proper integration with Proxmox and enable quick remote access via RDP. Here’s the exact workflow I use. Initial Setup After Installation After installing Ubuntu, I skip all optional extras: - Ubuntu Pro → I choose “Skip for now” - Help Improve Ubuntu → I select “No” Once I land on the desktop, I immediately update everything: - sudo apt update - sudo apt upgrade -y Installing QEMU Guest Agent One of the first things I install is the QEMU Guest Agent. It makes Proxmox much more aware of what’s happening inside the VM. - sudo apt install qemu-guest-agent -y After that, I shut the VM down: - sudo poweroff Then on the Proxmox side: - I remove the installation ISO (Hardware → CD/DVD → Remove) - I enable the QEMU Guest Agent (Options → QEMU Guest Agent → Enable) When I boot the VM again, I quickly check if it worked by looking at the Summary tab, if I see the IP address there, I know everything is working correctly. Setting Up XRDP For remote access, I usually go with XRDP since it’s simple and works well enough for most use cases. First, I install it: - sudo apt install xrdp -y Then I fix a small but common permission issue: - sudo adduser xrdp ssl-cert Next, I tweak the XRDP startup script: - sudo nano /etc/xrdp/startwm.sh At the top of the file, I add: - export DESKTOP_SESSION=ubuntu - export GNOME_SHELL_SESSION_MODE=ubuntu - export XDG_CURRENT_DESKTOP=ubuntu:GNOME After saving the file, I restart the service: - sudo systemctl restart xrdp Connecting to the VM At this point, I just grab the IP address from the Proxmox Summary tab and connect using any RDP client (Remmina). I log in with the same user I created during installation, and that’s it, I have a working GNOME desktop over RDP. Optional Notes If I happen to be using UFW, I also open the RDP port:

This may be super easy for everyone in here but it was a big accomplishment for me today. I have my own email linked to my personal domain. I wanted to be able to respond to customers using the gmail app on my phone. The problem was that all of my other emails ([email protected] for example) were not properly sending emails. They were able to receive, but if i replied it went into a "queued" status. The fix was to reenter all of my smtp info and resync with the gmail app. Everything is working great now. I love being able to fix a technical challenge that i have no background info for.

I’m currently testing different configurations for virtual machines in my Proxmox setup, and it reminded me of a story I once came across. I’m not sure if this story is entirely true, but it’s still worth telling. A few years ago, someone on a small DevOps forum shared a painful story. He had a “temporary” Ubuntu VM running on his home server—nothing public, just a test box behind NAT. He skipped hardening because “it’s not exposed anyway.” A few weeks later, one misconfigured port forward and a weak SSH setup were all it took. The machine got brute-forced overnight, quietly joined a botnet, and started sending spam. He only noticed when his ISP throttled his connection. That story stuck with me. Since then, I always do a minimal hardening routine—even for throwaway machines. Here’s what that looks like. 1. Create a non-root user First thing: stop using root. adduser myuserusermod -aG sudo myuser 2. Set up SSH keys On your local machine: ssh-keygen Copy the public key: ssh-copy-id myuser@server_ip Or manually place it in: ~/.ssh/authorized_keys Make sure permissions are correct: chmod 700 ~/.sshchmod 600 ~/.ssh/authorized_keys 3. Log in as the new user Reconnect: ssh myuser@server_ip Update the system: sudo apt update && sudo apt upgrade -y 4. Disable root SSH login Edit: sudo nano /etc/ssh/sshd_config Set: PermitRootLogin no Restart SSH: sudo systemctl restart ssh 5. Set hostname properly Edit: sudo nano /etc/hostname Use a fully qualified domain name if possible, for example: server.example.com Then update hosts: sudo nano /etc/hosts Modify: 127.0.1.1 server.example.com server 6. Reboot sudo reboot 7. Configure firewall (UFW) Install and enable: sudo apt install ufwsudo ufw allow OpenSSHsudo ufw enable 8. Install Fail2Ban sudo apt install fail2ban Default config already protects SSH reasonably well. 9. Change SSH port Edit: sudo nano /etc/ssh/sshd_config Change: Port 2222 Update firewall: sudo ufw allow 2222/tcpsudo ufw delete allow OpenSSH

For a while, one small thing was driving me crazy every time I powered on my Proxmox machine. Not the CPU. Not the storage. Not the software. The fan. It was loud. Constantly loud. Full speed from the moment the machine started. And once I noticed it, I couldn’t ignore it anymore. That’s the annoying part about hardware problems like this — they don’t stay in the background. They slowly take over your attention until fixing them becomes the only thing you can think about. So I started digging. I checked the socket type. I removed the motherboard. I measured the mounting holes. I confirmed what I needed. Only then did the search begin. The setup itself was nothing exotic: an Intel Core i5-6500 sitting on a Lenovo ThinkCentre M900 motherboard, model IQ1X0MS (30BC), with an LGA1151 socket. A budget CPU on a budget OEM board — simple on paper, but not so simple when the fan refuses to behave. At that point, the goal was clear. I didn’t need the biggest cooler. I needed the quietest practical solution. So I compared a few options: Noctua NH-D15 - extremely powerful, but probably more cooler than this CPU really needed. be quiet! Dark Rock Pro 5 - premium, silent, and also a bit overkill here. Endorfy Fortis 5 - a strong, balanced option with good value. Endorfy Fera 5 - compact, affordable, and practical. be quiet! Pure Rock 3 - quiet, sensible, and enough for a 65 W processor. And after thinking it through, the choice became obvious. I went with the be quiet! Pure Rock 3. It was reasonably priced was more than enough for the i5-6500.And it solved the problem without turning the build into something unnecessarily expensive or oversized. But the cooler alone was not the whole story. No more background irritation. No more fighting the machine every time I wanted to use it. Just a simple fix that made the whole setup feel right again. And honestly, sometimes that’s the best kind of upgrade - not the flashy one, but the one that quietly removes a problem you were tired of living with.