Saturday, September 5, 2026

OBS Browser Source Not Working? How to Interact With Web Pages Inside OBS Studio

If you're using OBS Studio to display a website, YouTube page, dashboard, live poll, chat widget, or web application, you may notice something confusing:

The webpage appears perfectly inside OBS — but you can't click anything.

This is usually not a broken Browser Source.

The key is understanding how OBS handles browser interaction.

The Problem

A typical OBS Browser Source looks like this:


OBS Studio
┌──────────────────────────────────────┐
│                                      │
│        WEB PAGE / YOUTUBE            │
│                                      │
│       [ Button ]                     │
│                                      │
└──────────────────────────────────────┘

The page is rendered by OBS, but clicking directly on the OBS preview isn't how you interact with the webpage.

OBS's official documentation describes Browser Source as an embedded web browser that can display web pages, local files, widgets, alerts and other browser-based content.

The solution is Interact.

The Correct Way to Interact With a Browser Source

First select your Browser Source in the Sources panel.

Then either:

Method 1 — Interact button

Select the Browser Source and click:

Interact

Method 2 — Right-click

Right-click the Browser Source:


Browser
   ↓
Right Click
   ↓
Interact

OBS will open an interaction window where you can use the webpage.

This is the intended workflow for interacting with Browser Sources.

Your OBS Screenshot

In the screenshot you provided, the Browser Source is actually loading successfully.

You can see the webpage rendered inside the Browser Source, which means:

Browser Source is working
Chromium/CEF is rendering the page
The URL is loading
OBS is receiving the webpage

The issue is therefore likely interaction, rather than loading.

What About "Page Permissions"?

This is where things can become confusing.

Your screenshot shows:

Page permissions → Full access to OBS

It may look like this setting controls whether you can click the webpage.

It doesn't.

OBS documentation describes Page Permissions as controlling whether the browser page can access or modify OBS-related information.

In other words:


Page Permissions
        │
        └── Webpage ↔ OBS communication

Interact
        │
        └── You ↔ Webpage

These are two different things.

Your Custom CSS May Also Cause Problems

Your screenshot contains:


body {
    background-color: rgba(0, 0, 0, 0);
    margin: 0px auto;
    overflow: hidden;
}

The important part is:


overflow: hidden;

This can prevent normal scrolling behavior.

OBS's default Browser Source CSS includes overflow: hidden, and OBS community discussions have specifically identified this as a reason scrolling can be problematic in Interact mode.

For troubleshooting, remove the CSS completely.

Go to:


Browser Source
→ Properties
→ Custom CSS

Delete:


body {
    background-color: rgba(0, 0, 0, 0);
    margin: 0px auto;
    overflow: hidden;
}

Click OK.

Then:


Right-click Browser Source
→ Interact

Test scrolling and clicking again.

A Better CSS for Interactive Pages

If you need the page to remain transparent but still allow scrolling, try:


body {
    background-color: rgba(0, 0, 0, 0);
    margin: 0;
    overflow: auto;
}

body::-webkit-scrollbar {
    display: none;
}

This keeps the scrollbar visually hidden while retaining scrolling behavior.

This approach is also consistent with solutions discussed in OBS community threads around Browser Source scrolling.

Test With a Simple Website First

Before troubleshooting YouTube or another complicated website, use a simple page.

Set the Browser Source URL to:


https://example.com

Then:


Browser Source
      ↓
Right Click
      ↓
Interact

Try clicking.

If this works, your OBS Browser Source is functioning correctly.

The problem is likely specific to the website you're trying to load.

YouTube Can Be More Complicated

Your screenshot appears to show YouTube content.

YouTube pages contain a lot of dynamic content:


JavaScript
iframes
login state
advertisements
cookies
dynamic UI
embedded players

Therefore, a YouTube page inside OBS's embedded browser isn't necessarily equivalent to opening YouTube in Chrome.

If your objective is simply:

Show YouTube in OBS

you may be better off using a normal browser/window capture depending on the workflow.

If your objective is:

Interact with YouTube while capturing it

you may instead want:


Chrome / Edge
      ↓
Window Capture
      ↓
OBS

Then you interact with Chrome normally.

Browser Source vs Window Capture

This distinction is important.

Feature	Browser Source	Window Capture
Display website	✅	✅
Interactive webpage	✅ Via Interact	✅ Normally
Scroll webpage	✅ Interact mode	✅
JavaScript widgets	✅	✅
OBS webpage overlays	⭐ Excellent	⚠️
YouTube browsing	⚠️	⭐
Web dashboards	⭐	⭐
Custom HTML	⭐⭐⭐	⭐
OBS-controlled webpage	⭐⭐⭐	❌
Capture normal Chrome	❌	✅

OBS itself recommends Browser Source for web-based content such as widgets and alerts, while Window Capture is intended to capture a specific application window.

If You Want a Webpage to Control OBS

This is a completely different and much more powerful use case.

For example, you could build your own control panel:


┌──────────────────────────────────────┐
│         MY OBS CONTROL PANEL                                                     │
├──────────────────────────────────────┤
│                                                                                                                      
│  [ START RECORDING ]                 │
│                                      │
│  [ STOP RECORDING ]                  │
│                                      │
│  [ INTRO SCENE ]                     │
│                                      │
│  [ NEWS SCENE ]                      │
│                                      │
│  [ END SCENE ]                       │
│                                      │
└──────────────────────────────────────┘

Then:


Browser Source
      ↓
JavaScript
      ↓
OBS WebSocket/API
      ↓
OBS Studio

In this scenario, Page Permissions becomes relevant because the webpage may need to communicate with OBS.

That's different from simply clicking a webpage.

Recommended Troubleshooting Sequence

If your Browser Source isn't responding:

1. Select Browser Source


Sources
→ Browser

2. Right-click


Interact

3. Test mouse

Try clicking a simple button.

4. Test keyboard

Click a text field and type.

5. Test scrolling

Use the mouse wheel.

6. Remove Custom CSS

Temporarily leave it completely blank.

7. Test `example.com`

If that works, test your actual website.

8. Test another browser source

This helps determine whether the problem is OBS or the website.

The Most Important Point

Your Browser Source doesn't need:


Page permissions → Full access to OBS

just to make the webpage clickable.

The basic workflow is:


Add Browser Source
       ↓
Enter URL
       ↓
Page loads
       ↓
Select Browser Source
       ↓
Right-click
       ↓
INTERACT
       ↓
Click / Type / Scroll

If you're using the exact setup shown in your screenshot, I would first remove the Custom CSS and then test the page through Interact. Your overflow: hidden rule is particularly worth checking if scrolling is the specific problem.

Useful official references

OBS Browser Source documentation

OBS Sources Guide

OBS Help Portal

#OBSStudio, #OBS, #BrowserSource, #OBSBrowserSource, #OBSInteract, #Streaming, #LiveStreaming, #YouTubeStreaming, #OBSStudioTutorial, #OBSHelp, #ContentCreation, #StreamSetup, #StreamingTips, #OBSWebSource, #LiveProduction

Build Your Own Local AI Coding Agent: A Complete Multi-Platform Development System

Imagine telling your computer:

“Build me a Python application, test it, fix the errors and package it.”

Or:

“Create an Android application and generate the APK.”

Or even:

“Build this .NET application for Windows.”

Instead of sending your source code to a cloud AI service, you could have your own local AI coding agent running on your computer.

The agent can understand requirements, write code, execute commands, run tests, debug errors, build applications and manage Git repositories.

Even better, the system can support multiple programming languages and platforms.

The practical way to build such a system is to use Windows as the host, an Ubuntu virtual machine as the development environment, local AI through Ollama, and specialized build machines for Windows and Apple platforms.

The Architecture

The overall architecture looks like this:

                         WINDOWS 11 PRO
                              │
              ┌───────────────┴────────────────┐
              │                                │
         NVIDIA GPU                       Windows Tools
              │                                │
           Ollama                    Visual Studio / MSBuild
              │                                │
              └──────────────┬─────────────────┘
                             │
                       Hyper-V Network
                             │
                    ┌────────▼────────┐
                    │   UBUNTU VM    │
                    │                │
                    │ OpenHands      │
                    │ Cline          │
                    │ Aider          │
                    │ Docker         │
                    │ Git            │
                    │ Python         │
                    │ Java           │
                    │ .NET           │
                    │ C/C++          │
                    │ Rust           │
                    │ Go             │
                    │ Node.js        │
                    │ Android        │
                    │ Flutter        │
                    └────────┬───────┘
                             │
                             │ SSH
                             ▼
                       OPTIONAL MAC
                             │
                       Xcode / Swift
                             │
                         iOS / macOS

This architecture separates AI, development and platform-specific compilation.

That separation is important.

Linux does not need to do everything.

Why Use an Ubuntu VM?

You could install everything directly on Windows, but a dedicated Linux development environment provides several advantages.

Ubuntu gives you:

A clean development environment
Native Linux tooling
Docker
Python
Java
C/C++
Rust
Go
Node.js
.NET
Android development
Flutter
Linux builds
Easy automation
Easier agent sandboxing

Most importantly, the AI agent can operate inside a controlled environment without modifying your main Windows installation.

Your Windows machine remains your everyday desktop.

Ubuntu becomes your AI software factory.

Windows Remains Your Main Desktop

You don't have to sit inside the Ubuntu desktop all day.

Install VS Code on Windows and connect to Ubuntu using Remote SSH.

The experience looks like this:

Windows
   │
   ▼
VS Code
   │
   ▼
Ubuntu VM
   │
   ├── Source code
   ├── Git
   ├── Docker
   ├── Compilers
   └── AI agents

You see the familiar Windows VS Code interface.

But the code executes inside Ubuntu.

This gives you the best of both worlds.

Step 1: Enable Hyper-V

Windows 11 Pro includes Hyper-V.

Open PowerShell as Administrator and run:

Enable-WindowsOptionalFeature `
    -Online `
    -FeatureName Microsoft-Hyper-V `
    -All

Restart Windows after installation.

Then open:

Hyper-V Manager

Hyper-V will be the virtualization layer for your Ubuntu development machine.

Step 2: Create a Virtual Network

Open:

Hyper-V Manager
→ Virtual Switch Manager

Create an:

External Virtual Switch

Name it:

DevAgentSwitch

Connect it to your physical Ethernet or Wi-Fi adapter.

This allows your Ubuntu VM to communicate with:

Windows
Ollama
Other computers
Build servers
Future Mac machines

Step 3: Create the Ubuntu VM

Download the current Ubuntu LTS desktop ISO.

Create a new Hyper-V VM with approximately:

Resource	Recommended
Generation	Generation 2
CPU	12 virtual CPUs
RAM	32 GB
Disk	500 GB
Network	DevAgentSwitch
OS	Ubuntu LTS

If your system has 64 GB RAM, 32 GB allocated to the development VM is a good starting point.

You can change the allocation later.

Step 4: Install Ubuntu

Install Ubuntu normally.

A simple hostname is:

localdev

After installation:

sudo apt update
sudo apt upgrade -y

Reboot:

sudo reboot

Verify the resources:

nproc
free -h
df -h

Step 5: Enable SSH

SSH allows Windows to access Ubuntu directly.

Inside Ubuntu:

sudo apt install -y openssh-server

Enable the service:

sudo systemctl enable --now ssh

Find the Ubuntu IP:

hostname -I

For example:

192.168.1.50

From Windows PowerShell:

ssh dev@192.168.1.50

Now you can control Ubuntu directly from Windows.

Step 6: Use VS Code From Windows

Install VS Code on Windows and add the:

Remote - SSH

extension.

Connect to:

dev@192.168.1.50

Now your workflow becomes:

Windows Desktop
      ↓
VS Code
      ↓
Ubuntu VM
      ↓
Development Environment

You can open, edit, compile and test Linux projects without leaving Windows.

Step 7: Install Docker

Docker is critical because it allows the AI agent to work in isolated environments.

Install Docker Engine and Compose in Ubuntu.

After installation:

docker run hello-world

The objective is to eventually have separate development environments such as:

Python container
Java container
Node container
.NET container
Rust container
C++ container
Android container

This prevents dependencies from different projects from interfering with each other.

Step 8: Keep Ollama on Windows

This is an important architectural decision.

Your NVIDIA GPU is physically installed in the Windows machine.

Instead of making GPU passthrough work inside Hyper-V, initially keep Ollama on Windows.

The architecture becomes:

This is considerably simpler than configuring GPU passthrough.

Install Ollama on Windows and download a suitable coding model.

For example:

ollama run qwen3-coder:30b

The exact model/quantization you choose should depend on your available VRAM and system RAM.

Step 9: Connect Ubuntu to Ollama

The Ubuntu VM needs to communicate with Ollama running on Windows.

Conceptually:

Ubuntu
  │
  │ HTTP
  ▼
Windows:11434
  │
  ▼
Ollama
  │
  ▼
NVIDIA GPU

From Ubuntu, test the connection:

curl http://WINDOWS_IP:11434/api/tags

If the connection works, Ubuntu can use the Windows-hosted local model.

Do not expose Ollama's port to the public internet.

Keep it restricted to your private network.

Step 10: Install OpenHands

OpenHands will become the primary autonomous coding agent.

Install the required Python environment and OpenHands inside Ubuntu.

The resulting workflow is:

User
  ↓
OpenHands
  ↓
Local LLM
  ↓
Planning
  ↓
Code generation
  ↓
Terminal commands
  ↓
Testing
  ↓
Debugging
  ↓
Build

Unlike a simple autocomplete tool, an agent can perform multiple actions to accomplish a task.

Step 11: Add Cline

Cline can be used from VS Code for interactive development.

This gives you two different working modes:

OpenHands

Best for:

Autonomous tasks
Large projects
Long-running workflows
Testing
Debugging
Automation

Cline

Best for:

Interactive coding
Working directly inside VS Code
Reviewing changes
Making targeted modifications

You can connect both to your local Ollama instance.

Step 12: Add Aider

Aider gives you a powerful terminal-based interface.

For example:

aider --model ollama_chat/qwen3-coder:30b

You now have three interfaces:

              Local LLM
                  │
        ┌─────────┼─────────┐
        │         │         │
     OpenHands  Cline     Aider
        │         │         │
        └─────────┼─────────┘
                  │
              Git Project

Step 13: Install Programming Languages

The Ubuntu VM can become your universal development environment.

Install:

Python

sudo apt install python3 python3-venv python3-pip

Java

sudo apt install openjdk-21-jdk maven gradle

C/C++

sudo apt install build-essential gcc g++ clang cmake ninja-build

Go

sudo apt install golang-go

Rust

sudo apt install rustc cargo

Node.js

Install a current Node.js LTS environment.

.NET

Install the appropriate .NET SDK for the Ubuntu release.

The result is a single environment capable of working with:

Python
Java
Kotlin
C
C++
C#
.NET
Go
Rust
JavaScript
TypeScript
PHP
Ruby
and many others

Step 14: Android Development

Android is one of the major advantages of using Linux.

Install:

Android Studio
Android SDK
Android SDK Platform Tools
Android Emulator
Gradle

Then verify:

adb devices

The AI agent can eventually perform:

Generate project
      ↓
Write code
      ↓
Compile APK
      ↓
Launch emulator
      ↓
Install APK
      ↓
Run tests
      ↓
Read logcat
      ↓
Fix bugs
      ↓
Build final APK

This is where the system starts becoming genuinely autonomous.

Step 15: Flutter

Flutter is another important component.

A single Flutter project can target multiple platforms:

Android
iOS
Windows
Linux
macOS
Web

Linux can handle Android and Linux builds.

Windows can handle Windows builds.

A Mac can handle iOS and macOS builds.

This makes Flutter an excellent framework for the agent to use when cross-platform applications are required.

Step 16: Windows Application Builds

Your Windows host can act as the Windows build machine.

Install:

Visual Studio
MSBuild
Windows SDK
.NET SDK
CMake
Flutter

The architecture becomes:

Ubuntu Agent
      │
      │ Build request
      ▼
Windows Host
      │
      ▼
MSBuild / Visual Studio
      │
      ▼
EXE / MSIX

This means the AI can write code in Ubuntu while the native Windows toolchain performs the final build.

Step 17: macOS and iPhone

Apple platforms are different.

For genuine iOS/macOS builds, you eventually need a Mac running macOS and Xcode.

The architecture becomes:

Ubuntu
   │
   │ SSH
   ▼
Mac
   │
   ├── Xcode
   ├── Swift
   ├── CocoaPods
   └── iOS Simulator
          │
          ▼
       iOS build

The Mac doesn't need to run the AI.

It simply becomes your Apple build worker.

The Complete Build Pipeline

Once everything is implemented, a request such as:

Build an expense management application for Android and Windows.

could become:

USER REQUEST
     │
     ▼
AI PLANNER
     │
     ▼
Architecture
     │
     ▼
Technology Selection
     │
     ▼
CODE GENERATOR
     │
     ▼
Git Repository
     │
     ▼
Implementation
     │
     ▼
UNIT TESTS
     │
     ▼
BUILD
     │
 ┌───┴────┐
 │        │
Android  Windows
 │        │
 ▼        ▼
APK      EXE
 │        │
 └───┬────┘
     ▼
INTEGRATION TESTS
     │
     ▼
SECURITY REVIEW
     │
     ▼
DOCUMENTATION
     │
     ▼
RELEASE ARTIFACTS

The AI becomes more than a code generator.

It becomes a software engineering system.

The Project Structure

A useful directory structure is:

~/local-agent/

├── core/
│   ├── planner/
│   ├── coder/
│   ├── reviewer/
│   ├── debugger/
│   └── tester/
│
├── orchestrator/
│
├── builders/
│   ├── linux/
│   ├── windows/
│   ├── android/
│   └── macos/
│
├── runtimes/
│   ├── python/
│   ├── java/
│   ├── dotnet/
│   ├── node/
│   ├── rust/
│   └── cpp/
│
├── projects/
├── artifacts/
├── logs/
└── config/

This gives us a foundation for building a custom orchestration layer.

Add Git to Everything

Every project should be managed through Git.

The agent should follow a workflow such as:

Create branch
     ↓
Understand project
     ↓
Modify code
     ↓
Run formatter
     ↓
Run tests
     ↓
Build
     ↓
Review diff
     ↓
Commit

You should never allow an autonomous agent to blindly modify your only copy of a project.

Git becomes the safety net.

Add Agent Rules

Every repository can contain an AGENTS.md file.

For example:

Before modifying code:

1. Read the project documentation.
2. Inspect the existing architecture.
3. Do not delete working functionality unnecessarily.
4. Create a Git branch.
5. Implement the requested change.
6. Run formatting.
7. Run static analysis.
8. Run unit tests.
9. Build the application.
10. Fix failures.
11. Review the Git diff.
12. Commit only when validation succeeds.

This makes agent behavior considerably more predictable.

The Final System

Ultimately your computer becomes a local development platform:

                       LOCAL AI SOFTWARE FACTORY

                              USER
                               │
                               ▼
                        WEB DASHBOARD
                               │
                               ▼
                         AI ORCHESTRATOR
                               │
               ┌───────────────┼────────────────┐
               │               │                │
            Planner          Coder           Reviewer
               │               │                │
               └───────────────┼────────────────┘
                               │
                         Local LLM
                          Ollama
                               │
                               ▼
                         OpenHands
                               │
                     ┌─────────┴─────────┐
                     │                   │
                  Docker               Git
                     │                   │
                     ▼                   ▼
              Development             Repository
              environments
                     │
        ┌────────────┼─────────────┐
        │            │             │
      Linux       Windows         Mac
        │            │             │
      Build        Build          Xcode
        │            │             │
       APK         EXE           IPA

What Makes This Different?

A normal AI coding assistant might give you:

code

A local coding agent can potentially give you:

requirements
→ architecture
→ source code
→ dependencies
→ tests
→ debugging
→ builds
→ artifacts
→ documentation

And because the entire development environment can remain local, your source code and internal projects don't have to be sent to a third-party AI API.

Recommended Implementation Order

Don't attempt to install everything simultaneously.

Build the system in these phases:

PHASE 1
Windows + Hyper-V
        ↓
PHASE 2
Ubuntu VM
        ↓
PHASE 3
SSH + VS Code
        ↓
PHASE 4
Docker
        ↓
PHASE 5
Windows Ollama + local coding model
        ↓
PHASE 6
OpenHands
        ↓
PHASE 7
Cline + Aider
        ↓
PHASE 8
Python / Java / .NET / C++ / Rust / Go / Node
        ↓
PHASE 9
Android + Flutter
        ↓
PHASE 10
Windows build automation
        ↓
PHASE 11
Mac/iOS build worker
        ↓
PHASE 12
Custom AI orchestrator
        ↓
PHASE 13
Web dashboard
        ↓
PHASE 14
Autonomous testing + deployment

Final Recommendation

For a powerful personal development environment, don't replace Windows with Linux immediately.

Instead, use:

Windows 11 Pro → Hyper-V → Ubuntu development VM → Ollama on Windows GPU → OpenHands/Cline/Aider in Ubuntu → Docker → native Windows build tools → optional Mac build node.

This gives you a flexible architecture where each platform does what it is best at.

The most important principle is:

One AI brain, multiple specialized build environments.

That is the architecture that can eventually turn your PC into a local, private, multi-language, multi-platform AI software factory.

#LocalAI, #CodingAgent, #AICoding, #LocalLLM, #Ollama, #OpenHands, #Cline, #Aider, #Ubuntu, #HyperV, #Docker, #DevOps, #SoftwareDevelopment, #AIEngineering, #DeveloperTools

Saturday, August 15, 2026

How to Enable and Configure Remote Desktop (RDP) on Ubuntu 24.04.4 LTS

Remote Desktop Protocol (RDP) support in Ubuntu has become considerably easier with the GNOME Remote Desktop stack included in modern Ubuntu Desktop releases. On Ubuntu 24.04 LTS, you can use the built-in GNOME Remote Desktop implementation to connect from Windows using Microsoft's native Remote Desktop Connection (mstsc), without installing xrdp.

This guide explains the complete setup, including:

Installing and verifying GNOME Remote Desktop
Enabling RDP
Configuring RDP credentials
Understanding Desktop Sharing vs Remote Login
Finding the Ubuntu IP address
Configuring UFW
Connecting from Windows
Testing port 3389
Troubleshooting common RDP errors
Diagnosing the "Credentials are not set, denying client" error
Understanding grdctl
Security considerations
Headless-server considerations

The procedure is particularly useful for Ubuntu 24.04.4 LTS systems used as development servers, AI servers, lab machines, home servers, or workstations.

1. Ubuntu 24.04 Has Built-In RDP Support

Ubuntu Desktop 24.04 LTS uses GNOME Remote Desktop for its native remote desktop functionality.

The Ubuntu documentation describes two different remote-access modes:

Desktop Sharing

Desktop Sharing allows a remote computer to view and control the desktop session that is already running.

The important limitation is:

The user must already be logged into the graphical session.

This is useful when you want to remotely control the physical Ubuntu desktop.

Remote Login

Remote Login allows a user to log into the Ubuntu machine remotely.

This is generally the better option for a machine that is being used as a server or workstation that you want to access remotely without requiring somebody to already be logged into the graphical desktop.

Ubuntu documents these as separate features under:

Settings → System → Remote Desktop

Ubuntu 24.04: Share your desktop remotely

GNOME likewise documents Desktop Sharing and Remote Login as separate RDP functions.

2. What We Are Configuring

The basic architecture looks like this:

┌─────────────────────────────┐
│       Windows PC            │
│                             │
│ Remote Desktop Connection   │
│          mstsc.exe          │
└──────────────┬──────────────┘
               │
               │ RDP
               │ TCP 3389
               ▼
┌─────────────────────────────┐
│     Ubuntu 24.04.4 LTS      │
│                             │
│     GNOME Remote Desktop    │
│    gnome-remote-desktop     │
│                             │
│        GNOME Desktop        │
└─────────────────────────────┘

For a typical local-network installation:

Windows
192.168.1.x
     │
     │ TCP 3389
     ▼
Ubuntu
192.168.1.y

3. Check Whether GNOME Remote Desktop Is Installed

Open a terminal on Ubuntu:

apt policy gnome-remote-desktop

If it is installed, you will see a version such as:

Installed: 46.3-0ubuntu1.2

If it is not installed:

sudo apt update
sudo apt install gnome-remote-desktop

Ubuntu 24.04's GNOME Remote Desktop package provides the gnome-remote-desktop service and the grdctl configuration utility.

4. Check the GNOME Remote Desktop Service

Run:

systemctl --user status gnome-remote-desktop

Initially, you may see:

Loaded: loaded (...)
Active: inactive (dead)

That does not necessarily mean the installation is broken.

The service is a per-user systemd service, so its state is associated with the graphical user session.

Start it with:

systemctl --user start gnome-remote-desktop

To enable it:

systemctl --user enable gnome-remote-desktop

Or enable and start it together:

systemctl --user enable --now gnome-remote-desktop

Verify:

systemctl --user status gnome-remote-desktop

A successful result should contain:

Active: active (running)

and typically:

RDP server started

5. Enable the RDP Backend

GNOME Remote Desktop provides the grdctl command-line utility.

Check its help:

grdctl --help

Enable RDP:

grdctl rdp enable

You can also check the overall status:

grdctl status

The Ubuntu grdctl documentation defines commands including:

rdp enable
rdp disable
rdp set-credentials USERNAME PASSWORD
rdp clear-credentials

6. The Most Important Step: Configure RDP Credentials

One of the easiest mistakes to make is assuming that your normal Ubuntu password is automatically the password used by GNOME Desktop Sharing.

It isn't necessarily.

Ubuntu's documentation explicitly states that the remote desktop username and password can be different from the normal system login credentials.

This distinction is extremely important.

Use:

grdctl rdp set-credentials USERNAME PASSWORD

For example:

grdctl rdp set-credentials shashwat 'YOUR_RDP_PASSWORD'

Replace YOUR_RDP_PASSWORD with a strong password.

Do not put your real password into documentation, screenshots, support tickets, or chat messages.

The command syntax is:

grdctl rdp set-credentials USERNAME PASSWORD

This is documented by Ubuntu's grdctl manual.

Why the command may fail

A common mistake is:

grdctl rdp set-credentials shashwat

This produces:

Wrong number of arguments for subcommand 'set-credentials'

The reason is that the command requires both:

USERNAME
PASSWORD

Therefore:

grdctl rdp set-credentials shashwat 'YourPassword'

is the correct form.

7. Restart GNOME Remote Desktop

After configuring the credentials:

systemctl --user restart gnome-remote-desktop

Check:

systemctl --user status gnome-remote-desktop --no-pager

You want:

Active: active (running)

8. Find the Ubuntu IP Address

Run:

hostname -I

For more precise IPv4 information:

ip -4 address

You may see:

192.168.1.12

That is the address Windows can use if both systems are on the same LAN.

Ubuntu's documentation also recommends using the machine's IPv4 address or hostname when connecting.

9. Verify That RDP Is Listening

RDP normally uses TCP port:

Check:

ss -lntp | grep 3389

A listening socket indicates that something is accepting connections on that port.

You can also check more generally:

ss -lntp | grep -E '3389|3390'

This is useful because Ubuntu can use a second RDP port when both Desktop Sharing and Remote Login are enabled.

10. Configure the Ubuntu Firewall

Check UFW:

sudo ufw status

If it is inactive:

Status: inactive

then UFW is not blocking the connection.

If it is active, allow RDP.

For a simple setup:

sudo ufw allow 3389/tcp
sudo ufw reload

Ubuntu's current documentation gives the broader example:

sudo ufw allow 3389:3390/tcp
sudo ufw reload

because Desktop Sharing and Remote Login can use 3389 and 3390 depending on which modes are enabled.

Better security on a home LAN

Instead of allowing RDP from every network:

sudo ufw allow from 192.168.1.0/24 to any port 3389 proto tcp

Adjust the subnet to match your network.

For example:

192.168.1.0/24

means:

192.168.1.1 - 192.168.1.254

11. Connect From Windows

Windows already includes an RDP client.

Press:

Win + R

Then enter:

mstsc

Press Enter.

In Computer, enter the Ubuntu IP:

192.168.1.12

Then click:

Connect

Windows will request credentials.

Enter the RDP credentials configured using:

grdctl rdp set-credentials

For example:

Username: shashwat
Password: <your RDP password>

GNOME officially lists Microsoft's built-in mstsc client as a supported client.

12. Testing the Connection From Windows

If the Windows RDP client says:

This computer can't connect to the remote computer.

don't immediately reinstall anything.

First determine whether Windows can reach the Ubuntu RDP port.

Open PowerShell on Windows:

Test-NetConnection 192.168.1.12 -Port 3389

Replace the IP with your Ubuntu server's actual address.

A successful result contains:

TcpTestSucceeded : True

If you get:

TcpTestSucceeded : False

the problem is probably:

Wrong IP
Ubuntu firewall
Windows firewall/network isolation
Router/VLAN isolation
Wrong RDP port
GNOME RDP not listening

If TCP succeeds but authentication fails, investigate credentials and GNOME Remote Desktop configuration.

13. A Real-World Troubleshooting Example

One particularly useful diagnostic scenario occurs when the GNOME Remote Desktop service appears perfectly healthy:

● gnome-remote-desktop.service
   Active: active (running)

and:

RDP server started

but Windows still reports:

This computer can't connect to the remote computer.

The service log may reveal:

[RDP] Credentials are not set, denying client

This message is extremely valuable.

It means:

The RDP server is running and receiving the connection, but authentication is being rejected because RDP credentials have not been configured.

The solution is:

grdctl rdp set-credentials shashwat 'YOUR_RDP_PASSWORD'

followed by:

systemctl --user restart gnome-remote-desktop

This is very different from a network connectivity problem.

14. How to Read the GNOME Remote Desktop Logs

Run:

journalctl --user -u gnome-remote-desktop -n 50 --no-pager

For live monitoring:

journalctl --user -u gnome-remote-desktop -f

Then attempt an RDP connection from Windows.

The log will often immediately tell you what is happening.

For example:

RDP server started

RDP server started

Generally indicates that the daemon successfully started its RDP listener.

Credentials missing

[RDP] Credentials are not set, denying client

Configure:

grdctl rdp set-credentials USERNAME PASSWORD

Service inactive

Active: inactive (dead)

Start it:

systemctl --user enable --now gnome-remote-desktop

15. Desktop Sharing vs Remote Login

This distinction deserves special attention.

Desktop Sharing

Desktop Sharing is intended for controlling an existing graphical session.

Ubuntu's documentation states that you must be logged into the graphical session before another computer can connect using Desktop Sharing.

Typical use:

Physical Ubuntu desktop
        ↓
User logs in
        ↓
Desktop Sharing enabled
        ↓
Windows connects
        ↓
Same desktop session is controlled

This is useful for:

Remote assistance
Accessing your workstation
Controlling applications already running
Remote administration while somebody is logged in

16. Remote Login Is Better for a Headless Machine

Remote Login is different.

With Remote Login, you can remotely log into your Ubuntu account rather than simply taking control of an already-running desktop session.

Ubuntu documents this under:

Settings → System → Remote Desktop → Remote Login

This is generally the better configuration for:

Home servers
AI servers
Development servers
Lab machines
Machines without a monitor
Machines that are rebooted remotely
Systems that nobody needs to log into physically

Ubuntu's documentation notes that with Remote Login the user can log into their account remotely, while Desktop Sharing is intended for the already-running desktop session.

17. Understanding Ports 3389 and 3390

A common source of confusion is the RDP port.

Normally:

RDP → TCP 3389

However, Ubuntu's GNOME implementation can use another port when both Remote Login and Desktop Sharing are enabled.

Ubuntu documents this behavior:

Remote Login → 3389
Desktop Sharing → 3390

when both are enabled.

Therefore, if Windows cannot connect to:

192.168.1.12

check the port being advertised by Ubuntu.

You can also test:

Test-NetConnection 192.168.1.12 -Port 3390

if Desktop Sharing is configured on 3390.

In Windows Remote Desktop, specify a non-default port as:

192.168.1.12:3390

18. Checking the Configuration From the Ubuntu GUI

The graphical configuration is available under:

Settings
   ↓
System
   ↓
Remote Desktop

Depending on your configuration, you'll see options such as:

Desktop Sharing
Remote Control
Remote Login

Desktop Sharing

Enable:

Desktop Sharing

and, if you want to control the machine:

Remote Control

Remote Login

Enable:

Remote Login

for a login-oriented/headless workflow.

Ubuntu's documentation confirms that both are configured from the Remote Desktop settings panel.

19. Useful `grdctl` Commands

grdctl is the command-line administration tool for GNOME Remote Desktop.

Show general status

grdctl status

Enable RDP

grdctl rdp enable

Disable RDP

grdctl rdp disable

Set credentials

grdctl rdp set-credentials USERNAME PASSWORD

Clear credentials

grdctl rdp clear-credentials

Display help

grdctl --help

The exact command set can vary between GNOME Remote Desktop releases, so it is a good practice to check:

grdctl --help
grdctl rdp --help

rather than assuming that a command from another Ubuntu/GNOME version exists.

Ubuntu's grdctl manpage documents status, rdp enable, rdp disable, credential configuration, and other RDP controls.

20. Why `grdctl rdp status` May Not Work

A common mistake is trying:

grdctl rdp status

and receiving:

Unknown subcommand 'status'

This is not necessarily an installation problem.

The status command is a general grdctl command:

grdctl status

rather than:

grdctl rdp status

This distinction matters because grdctl has a hierarchy:

grdctl
 ├── status
 └── rdp
      ├── enable
      ├── disable
      ├── set-credentials
      └── ...

The exact command availability depends on the installed version.

21. Complete Command-Line Setup

For a typical Ubuntu Desktop 24.04 system where the user is already logged into GNOME, the basic configuration is:

sudo apt update
sudo apt install gnome-remote-desktop

Enable RDP:

grdctl rdp enable

Configure credentials:

grdctl rdp set-credentials shashwat 'YOUR_RDP_PASSWORD'

Enable and start the service:

systemctl --user enable --now gnome-remote-desktop

Check:

systemctl --user status gnome-remote-desktop --no-pager

Check general configuration:

grdctl status

Find the IP:

hostname -I

Check RDP:

ss -lntp | grep 3389

Check firewall:

sudo ufw status

If necessary:

sudo ufw allow 3389/tcp
sudo ufw reload

Then connect from Windows:

mstsc

and enter:

Ubuntu-IP

22. Recommended Diagnostic Sequence

If RDP doesn't work, don't randomly reinstall packages.

Use this sequence.

Step 1 — Check the service

systemctl --user status gnome-remote-desktop --no-pager

Step 2 — Check the RDP configuration

grdctl status

Step 3 — Check the IP

hostname -I

Step 4 — Check listening ports

ss -lntp | grep -E '3389|3390'

Step 5 — Check firewall

sudo ufw status

Step 6 — Test from Windows

Test-NetConnection UBUNTU_IP -Port 3389

Step 7 — Check logs

journalctl --user -u gnome-remote-desktop -n 50 --no-pager

Step 8 — Monitor while connecting

journalctl --user -u gnome-remote-desktop -f

This approach separates:

Network problem
      ↓
Port problem
      ↓
Service problem
      ↓
Authentication problem
      ↓
Desktop-session problem

That makes troubleshooting much faster.

23. Common Problems and Solutions

Problem	Likely Cause	Solution
Service inactive	GNOME RDP daemon not running	`systemctl --user enable --now gnome-remote-desktop`
RDP server started but connection rejected	Credentials missing	`grdctl rdp set-credentials USER PASSWORD`
Windows cannot reach port	Firewall/network	Check UFW and `Test-NetConnection`
3389 doesn't work	Different RDP mode/port	Check Desktop Sharing/Remote Login
Desktop Sharing doesn't work after reboot	Nobody logged into GNOME	Use Remote Login
Wrong screen resolution	Desktop Sharing uses existing session resolution	Use Remote Login for client-sized session
`grdctl rdp status` fails	Unsupported command	Use `grdctl status` and `grdctl --help`
Hostname doesn't resolve	Local DNS/mDNS issue	Use the Ubuntu IP address
Works locally but not remotely	Router/NAT/VPN issue	Use a VPN rather than exposing RDP

Ubuntu's documentation specifically recommends checking credentials, hostname/IP, port, server state, graphical login state for Desktop Sharing, and firewall configuration when troubleshooting.

24. Security: Do Not Expose RDP Directly to the Internet

This is one of the most important parts of the setup.

Avoid creating a router rule such as:

Internet
   ↓
TCP 3389
   ↓
Ubuntu server

unless you fully understand the security implications and have additional controls in place.

Ubuntu explicitly warns that port forwarding exposes the system to the world and creates a security risk. Its documentation recommends using a VPN when remote access is intended for a private group.

For remote access from outside your home network, a safer architecture is:

Laptop
   │
   │ Encrypted VPN
   ▼
Home Network
   │
   ▼
Ubuntu
   │
   │ RDP
   ▼
GNOME Desktop

Examples of VPN approaches include:

WireGuard
Tailscale
A corporate VPN
Site-to-site VPN

The general principle is:

Keep RDP private; expose the VPN, not RDP.

25. RDP vs SSH

RDP and SSH serve different purposes.

SSH

Best for:

Server administration
Running commands
File transfers
Automation
Scripts
System maintenance

Example:

ssh shashwat@192.168.1.12

RDP

Best for:

Full graphical desktop
GUI applications
Browsers
Development environments
Desktop administration
Applications requiring a graphical interface

A useful server configuration is therefore:

SSH → command-line administration
RDP → graphical administration

26. RDP vs xrdp

Many older Ubuntu tutorials recommend installing:

sudo apt install xrdp

For Ubuntu 24.04 GNOME Desktop, that should not automatically be your first choice.

Ubuntu 24.04's native GNOME Remote Desktop stack already provides RDP functionality, and Ubuntu documents it as the native approach for current Ubuntu Desktop releases.

Using the built-in GNOME implementation avoids introducing another RDP server unless you have a specific reason to use xrdp.

xrdp can still be useful in particular environments, but it should be treated as an alternative architecture rather than a prerequisite for Ubuntu 24.04 GNOME RDP.

27. Desktop Sharing Resolution vs Remote Login Resolution

There is another practical difference between the two modes.

With Desktop Sharing, the remote client is essentially viewing the existing graphical session, so its resolution is determined by the server's user session. Ubuntu notes that this can result in a screen that appears too small, too large, or blurry.

With Remote Login, the remote session's resolution is determined by the client window, so the session can better match the remote display.

For a laptop connecting to a server, Remote Login can therefore provide a much better experience.

28. Recommended Configuration for a Home AI/Development Server

For a machine such as an Ubuntu AI/development server, I would generally structure remote access like this:

                 ┌───────────────────┐
                 │ Windows Workstation│
                 └─────────┬─────────┘
                           │
                       VPN / LAN
                           │
                 ┌─────────▼─────────┐
                 │ Ubuntu 24.04 LTS  │
                 │                   │
                 │ ┌───────────────┐ │
                 │ │ SSH           │ │
                 │ │ Administration│ │
                 │ └───────────────┘ │
                 │                   │
                 │ ┌───────────────┐ │
                 │ │ GNOME RDP     │ │
                 │ │ GUI Access    │ │
                 │ └───────────────┘ │
                 └───────────────────┘

For LAN-only access:

Windows → Ubuntu:3389

For remote access:

Windows → VPN → Ubuntu:3389

Avoid:

Windows → Internet → Ubuntu:3389

29. Quick Reference

Install

sudo apt update
sudo apt install gnome-remote-desktop

Enable RDP

grdctl rdp enable

Configure credentials

grdctl rdp set-credentials USERNAME PASSWORD

Start service

systemctl --user enable --now gnome-remote-desktop

Check service

systemctl --user status gnome-remote-desktop

Check configuration

grdctl status

Find IP

hostname -I

Check RDP port

ss -lntp | grep 3389

Check firewall

sudo ufw status

Allow RDP

sudo ufw allow 3389/tcp
sudo ufw reload

Test from Windows

Test-NetConnection UBUNTU_IP -Port 3389

Monitor logs

journalctl --user -u gnome-remote-desktop -f

30. Final Checklist

Before attempting a Windows RDP connection, verify:

Conclusion

Ubuntu 24.04.4 LTS provides a capable native RDP solution through GNOME Remote Desktop, making it possible to connect from Windows using the built-in Remote Desktop Connection client without installing xrdp.

The most important concepts are:

GNOME Remote Desktop
        +
RDP enabled
        +
RDP credentials configured
        +
Correct IP/port
        +
Firewall allowing RDP
        =
Working Windows → Ubuntu Remote Desktop

The most easily overlooked component is RDP authentication credentials. A running service does not necessarily mean that clients can authenticate. If the journal reports:

[RDP] Credentials are not set, denying client

the correct fix is to configure credentials with:

grdctl rdp set-credentials USERNAME PASSWORD

For ordinary desktop sharing, ensure the graphical user session is already active. For a server that should be accessible after reboot without somebody sitting at the physical console, Remote Login is generally the more appropriate GNOME feature.

For local-network administration, this gives Ubuntu a very convenient combination:

SSH → CLI/server administration
RDP → full graphical administration
VPN → secure remote access from outside the LAN

That combination is particularly effective for Ubuntu development, virtualization, AI, Docker, Kubernetes, and home-lab servers.

Official References

Ubuntu 24.04 RDP, Ubuntu Remote Desktop, Ubuntu 24.04.4 LTS Remote Desktop, GNOME Remote Desktop, Ubuntu RDP Windows, Windows to Ubuntu RDP, mstsc Ubuntu, grdctl, Ubuntu Desktop Sharing, Ubuntu Remote Login, Linux Remote Desktop, Ubuntu RDP troubleshooting, Ubuntu 24.04 remote access, GNOME RDP, Ubuntu server GUI access

WebHosting

Saturday, September 5, 2026

OBS Browser Source Not Working? How to Interact With Web Pages Inside OBS Studio

The Problem

The Correct Way to Interact With a Browser Source

Method 1 — Interact button

Method 2 — Right-click

Your OBS Screenshot

What About "Page Permissions"?

Your Custom CSS May Also Cause Problems

For troubleshooting, remove the CSS completely.

A Better CSS for Interactive Pages

Test With a Simple Website First

YouTube Can Be More Complicated

Browser Source vs Window Capture

If You Want a Webpage to Control OBS

Recommended Troubleshooting Sequence

1. Select Browser Source

2. Right-click

3. Test mouse

4. Test keyboard

5. Test scrolling

6. Remove Custom CSS

7. Test example.com

8. Test another browser source

The Most Important Point

Useful official references

Build Your Own Local AI Coding Agent: A Complete Multi-Platform Development System

The Architecture

Why Use an Ubuntu VM?

Windows Remains Your Main Desktop

Step 1: Enable Hyper-V

Step 2: Create a Virtual Network

Step 3: Create the Ubuntu VM

Step 4: Install Ubuntu

Step 5: Enable SSH

Step 6: Use VS Code From Windows

Step 7: Install Docker

Step 8: Keep Ollama on Windows

Step 9: Connect Ubuntu to Ollama

Step 10: Install OpenHands

Step 11: Add Cline

OpenHands

Cline

Step 12: Add Aider

Step 13: Install Programming Languages

Python

Java

C/C++

Go

Rust

Node.js

.NET

Step 14: Android Development

Step 15: Flutter

Step 16: Windows Application Builds

Step 17: macOS and iPhone

The Complete Build Pipeline

The Project Structure

Add Git to Everything

Add Agent Rules

The Final System

What Makes This Different?

Recommended Implementation Order

Final Recommendation

Saturday, August 15, 2026

How to Enable and Configure Remote Desktop (RDP) on Ubuntu 24.04.4 LTS

1. Ubuntu 24.04 Has Built-In RDP Support

Desktop Sharing

Remote Login

2. What We Are Configuring

3. Check Whether GNOME Remote Desktop Is Installed

4. Check the GNOME Remote Desktop Service

5. Enable the RDP Backend

6. The Most Important Step: Configure RDP Credentials

Why the command may fail

7. Restart GNOME Remote Desktop

8. Find the Ubuntu IP Address

9. Verify That RDP Is Listening

10. Configure the Ubuntu Firewall

7. Test `example.com`

19. Useful `grdctl` Commands

20. Why `grdctl rdp status` May Not Work