In the previous article of this series, we established a remote desktop session between your Windows workstation and an Ubuntu or Debian Linux server. We successfully routed the display, keyboard, and mouse over RDP.

However, upon logging in for the first time, you likely noticed something missing: silence.

Unlike a standard desktop installation where audio starts automatically when you log into the graphical interface, a headless Linux server does not have a default “Login Screen” to trigger sound services. Consequently, even if your server has sound hardware installed (or is an emulated sound card in a VM), XRDP will pass the video stream perfectly while dropping all audio packets because the background service isn’t running yet.

This guide details how to configure PulseAudio specifically for headless Linux servers so you can route system sound from your remote session back to your Windows machine.

Prerequisites

1. XRDP Installed: You should have completed Part 1 of this guide and be able to remote into the desktop.
2. Hardware: Your server must have access to sound hardware. On a dedicated physical machine, this requires a sound card. On a Virtual Machine (VMware/VirtualBox/KVM), you must ensure the virtual machine is configured with an audio controller (usually “Intel HD Audio” or “AC97”).

Step 1: Install PulseAudio and Debug Tools

Ubuntu and Debian use PulseAudio as their default sound server. We need to install the daemon itself, along with a utility called pavucontrol (PulseAudio Volume Control). While you won’t use it every day, it is essential for debugging why audio might be muted or routed incorrectly later.

sudo apt update
sudo apt install pulseaudio pavucontrol libpulse-dev -y

• libpulse-dev: This package is crucial if your XRDP installation wasn’t compiled with sound support built-in; it ensures the necessary libraries are present for binding to the audio system.

Step 2: Enable Sound in XRDP Configuration

XRDP, by default, may attempt to ignore sound requests to save resources on the server. We need to explicitly tell it to bridge audio to PulseAudio.

Open the sesman configuration file:

sudo nano /etc/xrdp/sesman.ini

Locate the section labeled [Xorg].

You will see a list of parameters such as param=Xvnc or arg=-config xrdp/xorg.conf.

Find the line that looks like this:

Sound=none

Change it to pulse.

Sound=pulse

Save and exit the file (Ctrl+O, Enter, Ctrl+X).

Step 3: Start PulseAudio on Headless Servers (Crucial)

This is the specific step required for headless servers. On a PC with a monitor attached, the audio starts when you click “Login” at the greeter screen. On a headless server, there is no login screen, so we must create a trigger that starts the PulseAudio daemon automatically as soon as a user connects via XRDP.

We will do this by adding a startup script to the profile directory.

Create a new file for system-wide profile execution:

sudo nano /etc/profile.d/start_pulse.sh

Paste the following content into the file. This script checks if PulseAudio is running; if not, it starts it in system mode to bypass user session permission issues

#!/bin/bash
# Check if PulseAudio is already running
if ! ps -A | grep -v grep | grep pulseaudio > /dev/null
then
    echo "Starting PulseAudio for headless XRDP..."
    # Start as a daemon with high priority to prevent audio glitches
    /usr/bin/pulseaudio --system -D --daemonize=true 
fi

Make the script executable:

sudo chmod +x /etc/profile.d/start_pulse.sh

Permission Setup: Because we are running PulseAudio in “system mode” (allowing it to talk to hardware directly), we must grant your users permission to control the audio device. Create the system group:

sudo addgroup --system pulse-access

Add your primary user (and root, if necessary) to this group: # Replace 'username' with your actual login name

sudo usermod -aG pulse-access username

Step 4: Restart XRDP Services

Now that the software is installed and the scripts are in place, restart the XRDP services to apply the configuration changes.

sudo systemctl restart xrdp
sudo systemctl restart xrdp-sesman

Step 5: Configure Windows Remote Desktop Client

The server-side configuration allows audio to be captured, but your Windows computer needs to know where to send it. You may need to re-connect the session for these changes to take effect fully, or simply log out and log back in on the Linux side.

1. Open Remote Desktop Connection (mstsc.exe) on your Windows machine.
2. Click “Show Options” (or “Options” in newer versions).
3. Navigate to the Local Resources tab.
4. Under the Remote audio section, click “Settings…”.
5. Select “Play on this computer”.
6. From the dropdown menu, ensure your local speakers or headphones are selected.
7. Click OK, then Connect.

Troubleshooting Audio Issues

If you connect and still hear silence, follow these checks:

1. Check the Virtual Output
Once logged into your Linux desktop, open a terminal (Ctrl+Alt+T) and type:

pavucontrol

• Go to the Output Devices tab.
• If you see a “Fallback Device” but all sliders are grayed out or at 0%, right-click and enable it.
• Ensure it hasn’t been set to “Dummy Output.”

2. The First Connection Glitch
Sometimes, the very first connection after configuring start_pulse.sh may result in static or silence because the PulseAudio daemon takes a few seconds to initialize but XRDP has already grabbed the stream. Log out of the Linux session and log back in; the second attempt usually works perfectly.

3. Microphone Input (Optional)
If you need to use your Windows microphone on the Linux server:

• Go back to Local Resources > Remote Audio.
• Click Settings, then check “Record from this computer”.
• Note that your Linux audio levels in pavucontrol under the Input Devices tab must be unmuted.

Conclusion

With these steps completed, your headless Linux server is now a fully functional remote workstation. You have video over RDP, and you have system audio routed back to your local machine. This creates a truly seamless experience for running multimedia applications, listening to music, or attending conference calls directly through your Linux management server.

The post XRDP Guide: Part 2 — Enabling System Audio on Ubuntu and Debian appeared first on Triii Technologies LLC.

If you have spent years in system administration or IT support, you know the comfort of the Windows Remote Desktop Protocol (RDP). It offers a seamless bridge between your workstation and a server—complete with clipboard sharing, drive mapping, and that familiar window management feel.

However, managing Linux servers often forces you to switch contexts: opening SSH terminals, relying heavily on command-line tools like htop or top, and occasionally wrestling with VNC (Virtual Network Computing). While VNC is a powerful tool, it often feels clunky compared to the polished experience of RDP.

What if you could manage your Ubuntu or Debian Linux servers with the exact same familiarity as your Windows Server instances?

In this guide, we will set up XRDP (eXtended Remote Desktop Protocol) paired with the GNOME Desktop Environment. This allows you to use the native Microsoft “Remote Desktop” client on your PC to control a headless Linux machine just like it were another piece of Windows hardware.

Why XRDP over VNC?

Before we dive into the terminal, let’s discuss why this setup is often preferred for server management:

1. Performance: RDP generally requires less bandwidth than VNC, making it much smoother over slow or high-latency internet connections.
2. Client Familiarity: Every Windows machine has an RDP client installed by default. You don’t need to download third-party viewers like TightVNC or TigerVNC.
3. Feature Set: Native clipboard integration and drive redirection (accessing your local C: drive from the remote server) are much easier to configure.

Prerequisites

To follow this guide, you will need:

• A Linux Server: Ubuntu Server (20.04, 22.04, or 24.04 LTS) or Debian 11/12.
• Root/Sudo Access: You must have administrative privileges.
• GNOME Desktop Environment: This guide assumes you are installing the desktop on the server (headless setup).
• A Windows Workstation: The machine from which you will remote in.

Step 1: Update and Install GNOME

If your Linux installation is currently a bare-bones server with no graphics, we need to install the desktop environment first. While KDE or XFCE are lighter, GNOME provides the most polished “modern OS” feel similar to Windows 10/11.

Connect via SSH and run the following updates:

sudo apt update
sudo apt upgrade -y

Now, install the Ubuntu Desktop package (which works for Debian as well):

sudo apt install ubuntu-desktop gnome-panel gnome-settings-daemon metacity nautilus gnome-terminal -y

Note: During installation on Debian, you may be prompted to choose a display manager. Select gdm3.

Step 2: Installing XRDP

Now we install the server-side software that will translate the GNOME interface into RDP packets.

sudo apt install xrdp -y

Once installed, the XRDP service usually starts automatically. However, to be safe and ensure it runs at boot:

sudo systemctl enable xrdp
sudo systemctl start xrdp

Step 3: Configuring GNOME for XRDP (Crucial Step)

This is the most common point of failure. By default, GNOME often tries to launch a “Wayland” session when a user logs in locally or remotely. XRDP does not support Wayland. It requires Xorg. If you try to connect right now, you will likely get a black screen or an immediate disconnect.

We must force GNOME to use the X11 (Xorg) session specifically for XRDP. We do this by creating a specific session file in the user’s home directory.

Open the .xsession file in your text editor (replace username with your actual username):

sudo nano /home/username/.xsession

Note: The . at the beginning hides the file; this is correct behavior.

Paste the following configuration into the file:

export XDG_CURRENT_DESKTOP=GNOME
export XDG_SESSION_TYPE=x11
exec gnome-session

Save and exit (Ctrl+O, Enter, then Ctrl+X in nano). Now ensure the file has executable permissions so the system can run it upon connection:

sudo chmod +x /home/username/.xsession

(If you have multiple users who need access, you must repeat this step for each user’s home directory, or simply copy the configuration to /etc/skel/.xsession to apply it automatically to new users.)

Step 4: Firewall Configuration

XRDP listens on port 3389. If you are running a firewall (UFW is standard on Ubuntu/Debian), you must open this port or the connection will time out.

Check your firewall status:

sudo ufw status

Enable port 3389:

sudo ufw allow 3389/tcp

Security Tip: For a production environment, it is highly recommended to tunnel RDP over SSH rather than opening port 3389 to the entire public internet. However, for local network management, opening the port is standard practice.

Step 5: Connecting from Windows

You are now ready to bridge the gap.

1. On your Windows machine, open the Start Menu and type “Remote Desktop Connection”, then launch it.
2. In the Computer field, enter the IP address of your Linux server (e.g., 192.168.1.50).
3. Click Connect.

You will be presented with an XRDP login screen. It will look slightly different than a standard Windows RDP screen—usually gray or dark grey.

• Session: Ensure “Xorg” is selected in the dropdown (if it doesn’t default correctly).
• Username: Enter your Linux username.
• Password: Enter your Linux password.

Once authenticated, XRDP will load the GNOME desktop environment you installed earlier. You can now manage your server using a mouse and keyboard, open a terminal, or edit configuration files with text editors just like you would on Windows.

Troubleshooting Common Issues

“I get connected but it turns black immediately.”
This is almost always the .xsession issue described in Step 3. Ensure export XDG_SESSION_TYPE=x11 is present and that you have logged out of the GNOME desktop on the physical server (or via another SSH session) before trying the RDP connection again.

“The mouse cursor moves weirdly / doesn’t match.”
Adjust the display settings within your remote GNOME session. Right-click the desktop -> Display Settings. Ensure the resolution is set to a value supported by your local machine.

“I can’t type my password correctly (keyboard layout issues).”
This happens if your Windows client uses a different keyboard layout than the Linux server. Usually, simply logging out and back in fixes this, but you may need to configure /etc/default/keyboard on the server to match your physical keyboard (e.g., xkb-model="pc105").

Final Thoughts

Managing a Linux server does not have to mean staring at a blinking cursor forever. By bridging the gap with XRDP and GNOME, you gain the performance of a Linux kernel combined with the accessibility and familiarity of Windows Remote Desktop. It allows for easier maintenance of desktop-centric tools, graphical file managers (Nautilus), and web development environments without leaving your workstation’s comfort zone.

Welcome to the hybrid server environment!

The post Bridging the Gap: Managing Linux Servers with Windows Remote Desktop via XRDP appeared first on Triii Technologies LLC.

What you should know first

• There are two main kinds of NVIDIA driver packages:
  1. Unified Driver Architecture (UDA) — more “general purpose”, used for desktops/gaming.
  2. Enterprise Ready Drivers (ERD) / “-server” suffix — optimized for servers / compute workloads.
• If Secure Boot is enabled, you’ll need signed kernel modules or enroll a Machine Owner Key (MOK).
• Always check which kernel you’re running and make sure kernel headers for that version are installed. Without matching headers, driver modules may fail to compile.

Installation Methods

Here are the common ways to install, with pros & cons.

Step-by-Step (Ubuntu’s Recommended Route)

Here’s a streamlined version using Ubuntu’s ubuntu-drivers tool and APT.

Update system

sudo apt update

Check current driver version (if any) (if you haven’t installed a driver, you can skip this!)

cat /proc/driver/nvidia/version

List drivers available for your hardware (Optional)

For generic desktop/gaming:

sudo ubuntu-drivers list

For server / GPGPU / compute workloads:

sudo ubuntu-drivers list --gpgpu

You’ll see something like nvidia-driver-535, nvidia-driver-535-server, etc.

Install the driver

sudo ubuntu-drivers install

Reboot.

sudo reboot

After the system has rebooted, the drivers should now be installed and running. Try the nvidia-smi command.

Additional steps for power users. (Optional)

1. Install additional utils (optional/if needed)
   Especially for server drivers, you might want things like nvidia-utils-<version>, or for special hardware nvidia-fabricmanager or libnvidia-nscq. (Ubuntu Documentation)
2. Verify installation
   Use commands like: nvidia-smi to check GPU is recognized, see driver version, etc.

Removing / Switching Drivers

If things go wrong, or you want to switch versions:

1. Purge existing NVIDIA drivers ( sudo apt --purge remove '*nvidia*' sudo apt autoremove )
2. Then install the new one via above methods.

The post How to Install NVIDIA Drivers on Ubuntu 26.01 appeared first on Triii Technologies LLC.

In the Linux ecosystem, permissions are everything. Unlike some other operating systems where “admin” is a status you earn after a long tenure, in Linux, it’s strictly about group membership and ownership. Whether you are setting up a web server, a personal workstation, or a container environment, knowing how to manipulate users and groups is not just useful—it’s essential.

In this guide, we will cover everything from the basics of adduser and useradd to the nitty-gritty of group manipulation using command-line tools native to Ubuntu and Debian.

Prerequisites

To follow along with these examples, you need a terminal (bash) and root privileges.

• Root Access: Commands requiring system changes usually need sudo.
• The OS: Debian or Ubuntu derivatives (Linux Mint, Pop!_OS, etc.).

Part 1: The User Concept in Linux

A user account represents an individual or a service that needs to access the system. Every file and process on Linux belongs to a specific User ID (UID) and Group ID (GID).

Creating Users

On Debian/Ubuntu systems, you have two main tools for this: useradd and adduser. While they do similar things, they behave very differently.

1. The Interactive Way: adduser

This is the recommended way for human users on Debian/Ubuntu. It is a user-friendly Perl script that prompts for information, creates the home directory automatically, and copies skeleton files (like .bashrc).

Command:

bash

sudo adduser newuser

Example Output:

Adding user `newuser' ...

Adding new group `newuser' (1001) ...

Adding new user `newuser' (1001) with group `newuser' ...

Creating home directory `/home/newuser' ...

Copying files from `/etc/skel' ...

Enter new UNIX password:

Retype new UNIX password:

passwd: password updated successfully

Changing the user information for newuser

Enter the new value, or press ENTER for the default

Full Name []: New User

Room Number []:

Work Phone []:

Home Phone []:

Other []:

Is the information correct? [Y/n] Y

2. The Non-Interactive/Scriptable Way: useradd

This is the low-level binary command. It does not prompt for anything and does not create home directories by default. This makes it excellent for automation scripts but dangerous if you forget a flag.

Command:

bash

sudo useradd -m -s /bin/bash -c "John Doe" john

Flag Breakdown:

• -m: Create the home directory (/home/john).
• -s /bin/bash: Set the default shell to Bash (default might be /bin/sh).
• -c "John Doe": Add a comment/full name.

Part 2: Creating Users with Groups

Sometimes you want to assign a user to a specific group immediately upon creation, or set their primary group identity.

Setting the Primary Group (-g)

Every user must belong to one primary group. By default, useradd creates a private group with the same name as the user. You can change this at creation time.

Scenario: Create a user named webadmin whose primary group is www-data.

bash

sudo useradd -m -g www-data -s /bin/bash webadmin

Setting Supplementary Groups (-G)

You can assign the user to secondary groups (e.g., sudo, docker) at the moment of creation. Note the capital -G.

Scenario: Create a user devops who is in both the sudo and docker groups immediately.

bash

sudo useradd -m -s /bin/bash -G sudo,docker devops

Part 3: Managing Users

Once a user exists, you need to manage them.

Changing Passwords

Regardless of how the user was created, use passwd to set or change passwords.

bash

sudo passwd newuser

Force the user to change their password on next login (good for temporary accounts)

sudo passwd -e newuser

Modifying User Properties (usermod)

Use usermod to update existing users without deleting and recreating them.

Example 1: Locking an account (Disables the password, user cannot log in, but files remain).

bash

sudo usermod -L newuser

Example 2: Unlocking an account

bash

sudo passwd -u newuser

Example 3: Changing the home directory path (User moves to /opt/new_home)

bash

sudo usermod -d /opt/new_home -m newuser

(Note: -m is used here to move the contents of the old home dir to the new one).

Part 4: Creating and Managing Groups

Groups are logical collections of users used for access control.

Creating a Group (groupadd)

Command:

bash

sudo groupadd developers

If you want to assign a specific Group ID (GID) rather than letting the system pick one automatically:

bash

sudo groupadd -g 1050 developers

Deleting a Group (groupdel)

Warning: If users belong to this group, their GID will become orphaned.

bash

sudo groupdel developers

Part 5: Managing Group Memberships

This is where the real power of Linux permissions lies. You rarely change the definition of a group; you change the membership of users within it.

Adding a User to a Supplementary Group

The golden rule here is using usermod with -aG. You must include the ‘a’ (append). Without it, the user will be removed from all other groups and added only to this one!

Scenario: Add newuser to the sudo group (so they can become root) and the www-data group.

bash

sudo usermod -aG sudo,www-data newuser

Removing a User from a Group

It is easiest to use gpasswd.

Scenario: Remove newuser from the docker group.

sudo gpasswd -d newuser docker

Note: You cannot easily remove a user from their Primary group without using usermod -u to change their primary UID/GID entirely, which is complex.

Part 6: Verifying Your Work

How do you know if your changes stuck?

Check User Identity

bash

id newuser

Output:

uid=1001(newuser) gid=1001(newuser) groups=1001(newuser),27(sudo),33(www-data)

Check Group Members

Use getent (gets entries from databases) or cat /etc/group.

bash

getent group sudo

Output:

sudo:x:27:root,newuser

(This tells us users root and newuser are members of the sudo group).

Summary Cheatsheet for Calabastro Fans

Stay tuned, Linux lovers! Calabastro out.

The post The Ultimate Guide to User and Group Management in Ubuntu/Debian Linux appeared first on Triii Technologies LLC.

This tutorial walks you through the modern, zero-trust way to deploy Vaultwarden (a lightweight Bitwarden-compatible password manager) on Ubuntu 24.04, and secure access using Tailscale VPN. No port forwarding, no reverse proxy headaches, and no SSL certificate management required for initial setup.

Prerequisites

• Ubuntu 24.04 LTS (Server or Desktop)
• A user with sudo privileges
• A free Tailscale account (tailscale.com)
• Basic terminal familiarity

Step 1: Install & Authenticate Tailscale on Ubuntu 24.04

Tailscale replaces traditional VPN complexity with WireGuard-based mesh networking. It automatically handles NAT traversal, DNS, and firewall rules.

1. Install the Tailscale Client

Run the official automated installer:

bash

curl -fsSL https://tailscale.com/install.sh | sh

This script detects your APT package manager and sets up the tailscaled systemd service automatically.

2. Start & Authenticate the Client

bash

sudo tailscale up

You’ll see output containing an authentication URL like https://login.tailscale.com/a/.... Open that link in any browser, sign in with your Tailscale account, and authorize the device.

3. Verify Connectivity

bash

tailscale status

You should see your machine listed in the output. Head to your Tailscale Admin Console to confirm the device appears in your tailnet. Take note of the 4.x.x.x IPv4 address or the FQDN (e.g., yourhostname.tail-12345.tailnet.goog).

Step 2: Install Docker Engine

Ubuntu 24.04 no longer ships Docker in its default repositories. We’ll install it via Docker’s official APT repository.

bash

curl -fsSL https://get.docker.com -o get-docker.sh
sh get-docker.sh
rm get-docker.sh

Log out and back in for group permissions to apply. Verify with docker --version and docker compose version.

Step 3: Deploy Vaultwarden via Docker

Vaultwarden is a Rust-based, resource-efficient alternative to Bitwarden’s official server. We’ll run it with persistent storage.

1. Pull the Image

bash

docker pull vaultwarden/server:latest

2. Run the Container

bash

docker run -d \

--name vaultwarden \

--restart unless-stopped \

-v /vw-data:/data \

-p 8082:80 \

-e SIGNUPS_ALLOWED=false \

-e ADMIN_PASSWORD="$(openssl rand -base64 32)" \

-e ENABLE_DB_WAL=true \

vaultwarden/server:latest

Why this configuration?

• -v /vw-data:/data: Persists your vault database, attachments, and config across container updates.
• -p 8082:80: Maps to a non-privileged port to avoid conflicts with nginx/apache (optional but recommended).
• SIGNUPS_ALLOWED=false: Disables public registration (recommended for private setups).
• ADMIN_PASSWORD: Generates a secure random admin password. Save this! You’ll need it to access /admin.
• Tailscale’s encrypted tunnel means HTTP is perfectly secure here. The Chrome/Web Crypto HTTPS warning in the Vaultwarden docs applies to public internet exposure, which we’re bypassing entirely.

Verify it’s running:

bash

docker ps | grep vaultwarden

tailscale ip4

Step 4: Access Vaultwarden Securely Over Tailscale

Because Tailscale creates a private encrypted network, you can access Vaultwarden as if you’re on the same local machine.

1. On any device in your tailnet (Windows, macOS, Android, iOS, or another Ubuntu box), install the Tailscale client.
2. Open your browser and navigate to: http://<ubuntu-tailscale-ip>:8082(Replace <ubuntu-tailscale-ip> with the 4.x.x.x address from tailscale ip4)
3. Click Create Account and register as the first user.
4. Log in and set up your master password.
5. Install the Bitwarden browser extension or mobile app. In the extension settings, change the Server URI to your Tailscale address: http://<ubuntu-tailscale-ip:8082

You now have a fully functional, self-hosted password manager accessible only from your tailnet. No public IPs, no exposed ports, no reverse proxy required.

Pro Tips for Production-Ready Setups

Backups

bash

# Daily backup script (/vw-data contains everything)

sudo rsync -av /vw-data/ /mnt/backup/vaultwarden/

# Compress periodically

tar -czf /mnt/backup/vaultwarden-$(date +%F).tar.gz /vw-data/

Public Exposure (Optional)

If you ever want to access Vaultwarden over the public internet, you must enable HTTPS. Use certbot with a reverse proxy (Caddy or Nginx), or generate self-signed certs with mkcert. Never expose Vaultwarden over HTTP publicly.

Conclusion

Combining Vaultwarden with Tailscale gives you enterprise-grade access control, military-grade encryption, and zero infrastructure overhead. By leveraging Tailscale’s WireGuard mesh network, you eliminate the most common self-hosting pitfalls: NAT complications, SSL certificate management, and port exposure risks.

Your password manager is now:
Self-hosted & fully private
Accessible from anywhere via your tailnet
Secure by default (no public IPs or firewall rules needed)
Ready for scaling with Docker Compose & automated backups

Drop a comment if you run into authentication hiccups, need help configuring Bitwarden clients, or want to extend this setup with TOTP generation or emergency access features. Stay secure, stay private.

Published for Ubuntu 24.04 LTS | Tailscale & Vaultwarden versions current as of August 2026
Keywords: Ubuntu 24.04, Tailscale VPN, Vaultwarden, Docker, Self-Hosted Password Manager, Zero Trust Networking, Homelab Security

The post Secure Self-Hosted Password Management: Install Vaultwarden on Ubuntu 24.04 & Tunnel It with Tailscale appeared first on Triii Technologies LLC.