Oracle Linux 9 with GNOME Desktop on Azure User Guide

Overview

This guide covers the deployment and configuration of Oracle Linux 9 with the GNOME desktop on Microsoft Azure using cloudimg's pre configured virtual machine image from the Azure Marketplace.

Oracle Linux is Oracle's enterprise Linux distribution, binary compatible with Red Hat Enterprise Linux. Oracle publishes the binaries, updates and errata at no cost and permits redistribution, so no subscription is required. This image is Oracle Linux 9 with the distribution's own desktop added: the AppStream environment group @graphical-server-environment, which Oracle calls Server with GUI. You reach the desktop with any VNC viewer through TigerVNC, the VNC server Oracle ships in its own AppStream repository, and each user gets their own full GNOME session running on the virtual machine.

The image is built so that a freshly deployed machine exposes nothing but SSH. VNC ships switched off, no account has a password, no VNC password exists anywhere in the image, and when you do turn VNC on the server listens on localhost only, so you reach it through an SSH tunnel rather than over the internet.

What's included:

• Oracle Linux 9.8 with every available update applied at build time, binary compatible with RHEL 9
• Both kernels Oracle provides: the Unbreakable Enterprise Kernel (UEK) 6.12, which boots by default, and the Red Hat Compatible Kernel 5.14
• The GNOME desktop from Oracle's AppStream repository: GNOME Shell 40.10, the GDM 40 login screen and mutter 40.9
• Desktop applications from the same group, including Files, Terminal, Firefox, Text Editor, Calculator, System Monitor, Disks, Logs and Software
• TigerVNC 1.15 (tigervnc-server), configured for per user desktops on localhost only, with every offered security type requiring the VNC password
• cloudimg-vnc, a small helper that shows the VNC state and starts or stops a user's desktop in one command
• A real graphics device for the desktop on the Unbreakable Enterprise Kernel (see Step 12)
• Guest sleep disabled, so the desktop never offers a Suspend that would leave an Azure virtual machine unreachable
• dnf-automatic armed, so the machine keeps patching itself
• SELinux in enforcing mode and firewalld active, as Oracle ships them, with the Azure provisioning path unchanged (cloud-init, the Azure Linux Agent, NetworkManager)
• Gen2 Hyper V virtual machine support
• 24/7 cloudimg support

Like every Oracle Linux image on Azure, this image uses an LVM root layout. The root filesystem is the logical volume rootlv in volume group rootvg, next to a dedicated crashlv for kernel crash dumps.

Platform: Microsoft Azure (Gen2 Hyper V, x64) Default user: azureuser

Why VNC, and how it is locked down

On Oracle Linux 9 the distribution's own remote desktop options are limited. GNOME Remote Desktop on this release only shares a session that someone is already logged into at the machine, so it cannot give you a remote login on a cloud server, and xrdp is only available from Oracle's EPEL mirror, a third party package set this image does not use. TigerVNC is the first party way to run headless GNOME desktops on Oracle Linux 9, and it is what the RHEL 9 documentation describes for that job.

VNC's own password protocol is old: it uses only the first 8 characters of the password. That is why this image never exposes VNC to the network. The policy file /etc/tigervnc/vncserver-config-mandatory forces two settings for every user, and TigerVNC loads it after each user's own configuration, so a user's settings cannot undo it:

• localhost makes the VNC server listen on 127.0.0.1 and ::1 only. You connect through an SSH tunnel, which is encrypted and authenticated with your SSH key.
• securitytypes=tlsvnc,vncauth offers only security types that require the VNC password. None (no password) is never offered.

GDM runs with Wayland disabled (WaylandEnable=False in /etc/gdm/custom.conf), which RHEL 9 compatible systems require for TigerVNC desktops. Sessions are X11.

The two passwords, and which one goes where

Neither password exists until you create it, and both belong to you:

1. Your VNC password. You set it yourself by running vncpasswd as your own user, without sudo. It is stored at ~/.config/tigervnc/passwd, readable only by you. Your VNC viewer asks for it when it connects. Only the first 8 characters count.
2. Your account password. You set it yourself with sudo passwd <your-user>. The VNC session logs you straight into GNOME, but the desktop still asks for this password when the screen locks and when an application needs administrator rights. The image ships with no account password at all.

SSH stays key only throughout. Setting either password does not enable password logins over SSH.

Security posture

This image ships with no known credential:

• No account has a password. The root account is locked and your administrator account is created at first boot with only the SSH key you supply.
• SSH is key only (PasswordAuthentication no).
• No VNC password exists for any account. No VNC desktop is configured, the unauthenticated inetd mode xvnc.socket is disabled, and a new virtual machine listens on SSH port 22 only. Port 22 is the only port the listing advertises.
• The rpcbind portmapper ships enabled and listening on port 111 on the stock Oracle Linux cloud image. This image switches it off. It is still installed, and one command turns it back on (Step 14).
• firewalld is left active, as Oracle ships it and as every other cloudimg Oracle Linux image does. Its stale allowance for the Cockpit console, which ships switched off, has been removed, so the advertised firewall surface matches what is actually listening.
• When VNC is on, it listens on localhost only and every offered security type requires the VNC password. The SSH tunnel needs no firewalld rule.
• The helper refuses to start a desktop for a user who has no account password or no VNC password.
• Guest sleep is disabled, so the desktop menu offers Restart, Power Off and Log Out but never Suspend.
• SSH host keys are removed before capture and regenerated on each machine at first boot, and /etc/machine-id is regenerated per machine, so no two machines share a host identity. Firmware update tooling generates its own client key per machine as well.
• SELinux is left in enforcing mode, the Oracle Linux default, and GDM automatic login is not enabled.

Known issue: TigerVNC and CVE-2025-49177

CVE-2025-49177 is not fixed in the TigerVNC package on Oracle Linux 9. Red Hat has said it will not fix it on RHEL 9, and Oracle has published no Oracle Linux 9 TigerVNC erratum for it. Checked on 17 September 2026:

• Red Hat (Security Data API for CVE-2025-49177) lists tigervnc on Red Hat Enterprise Linux 9 as "Will not fix", severity Important, CVSS 3.1 score 6.1 with vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:L, which is a local attack vector. Red Hat's mitigation statement reads: "Mitigation for this issue is either not available or the currently available options don't meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability."
• Oracle (linux.oracle.com, CVE-2025-49177) describes it as: "A flaw was found in the XFIXES extension. The XFixesSetClientDisconnectMode handler does not validate the request length, allowing a client to read unintended memory from previous requests." Oracle rates the impact Important with a preliminary CVSS v3 base score of 5.5 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N), and the page's errata table lists a single erratum: "Oracle Linux version 10 (xorg-x11-server-Xwayland) ELSA-2025-9304". There is no Oracle Linux 9 entry and no TigerVNC entry.
• The Oracle Linux 9 update metadata on this image agrees: dnf updateinfo list --all --cve CVE-2025-49177 returns no advisory, while the same query for the sibling flaw CVE-2025-49176 returns ELSA-2025-9306. That Oracle Linux 9 TigerVNC advisory, "tigervnc security update", lists CVE-2025-49175, CVE-2025-49176, CVE-2025-49178, CVE-2025-49179 and CVE-2025-49180, and not CVE-2025-49177. The newest TigerVNC advisory, ELSA-2026-29844, which ships the tigervnc-server-1.15.0-7.el9_8.2 in this image, does not list it either.

A plain dnf updateinfo list --security reads empty on this image. That does not mean the flaw is fixed: a vulnerability the vendor will not fix never receives an advisory, so no advisory list can show it.

What cloudimg measured on this image, recorded as facts rather than as a claim that you are unaffected: the Xvnc server is built from the X.Org 1.20.11 code base, and XFixesSetClientDisconnectMode belongs to XFIXES protocol version 6. Xvnc runs as the desktop's own user and accepts X clients only through its local socket and that user's X authority cookie, with no X11 TCP port. VNC is off until you enable it. If your security policy does not accept an unfixed vendor CVE, do not enable VNC on this image. If Oracle publishes a fixed package, dnf-automatic applies it automatically.

Prerequisites

Before deploying this image, ensure you have:

1. An active Microsoft Azure subscription
2. Access to the Azure Portal or Azure CLI
3. An SSH key pair for Linux VM access
4. A VNC viewer: TigerVNC Viewer (Windows, macOS, Linux), RealVNC Viewer, Remmina on Linux, or the built in Screen Sharing app on macOS

Recommended VM Size: Standard_B2ms (2 vCPU, 8 GB RAM) or larger. Measured on this image: the login screen plus one idle GNOME VNC session uses about 1.4 GiB of memory, which fits in the 4 GB of Standard_B2s for light use, but a browser and a few applications quickly need the extra room. There is no GPU requirement: the desktop renders in software.

Step 1: Deploy the Virtual Machine

Option A: Azure Portal

1. Navigate to the Azure Marketplace and search for "Oracle Linux 9 with GNOME Desktop cloudimg"
2. Select the image and click Create
3. Configure the basics:
4. Subscription: Select your Azure subscription
5. Resource Group: Create new or select existing
6. Virtual Machine Name: Enter a name for your VM
7. Region: Select your preferred Azure region
8. Size: Standard_B2ms or larger
9. Under Administrator Account, select SSH public key and enter your key
10. Under Inbound Port Rules, allow SSH (port 22) only. Do not open any VNC port: the desktop is reached through an SSH tunnel
11. Click Review + Create, then Create

Option B: Azure CLI

Run this on your own workstation, substituting your resource group, VM name and preferred region. Accept the Marketplace terms once per subscription, then create the machine:

az vm image terms accept --urn cloudimg1647283583153:oel-9-gui:default:latest

az vm create \
  --resource-group myResourceGroup \
  --name my-oracle-linux-desktop \
  --image cloudimg1647283583153:oel-9-gui:default:latest \
  --size Standard_B2ms \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

Step 2: Connect via SSH

Run these on your own workstation, not on the VM. Find the public IP, then connect:

az vm show --resource-group myResourceGroup --name my-oracle-linux-desktop --show-details --query publicIps -o tsv
ssh azureuser@<vm-ip>

There is no password to enter. If SSH asks you for one, the key you supplied at create time is not the key your client is offering.

Step 3: Confirm the release and the desktop

Check that the machine is Oracle Linux 9 on the Unbreakable Enterprise Kernel, that it boots to the graphical target, that the GNOME login screen (GDM) is running with Wayland disabled, and which desktop and VNC packages are installed:

cat /etc/oracle-release
uname -srm
systemctl get-default
systemctl is-active gdm.service
grep '^WaylandEnable' /etc/gdm/custom.conf
rpm -q --qf '%{NAME} %{VERSION}\n' gdm gnome-shell mutter xorg-x11-server-Xorg tigervnc-server

Expected output:

Oracle Linux Server release 9.8
Linux 6.12.0-206.104.3.3.el9uek.x86_64 x86_64
graphical.target
active
WaylandEnable=False
gdm 40.1
gnome-shell 40.10
mutter 40.9
xorg-x11-server-Xorg 1.20.11
tigervnc-server 1.15.0

The desktop and TigerVNC come from Oracle's own repositories, not from a third party repository:

dnf group list --installed 2>/dev/null | grep -i 'Server with GUI' || true
dnf repolist
echo "packages installed: $(rpm -qa | wc -l)"
df -h /

dnf repolist shows exactly ol9_UEKR8, ol9_addons, ol9_appstream and ol9_baseos_latest, Oracle's rolling Oracle Linux 9 repositories. No EPEL repository is enabled, and none is configured.

Step 4: Check that VNC is off

A new virtual machine has VNC switched off. The helper shows the whole picture in one command:

sudo cloudimg-vnc status

Expected output on a new VM:

VNC policy: localhost only, security types tlsvnc,vncauth (/etc/tigervnc/vncserver-config-mandatory)
xvnc.socket (unauthenticated mode): disabled / inactive
VNC desktops configured: none
listening on VNC ports 5900-5999: none
users with a VNC password set: none (each user runs: vncpasswd)

The helper lives at /usr/local/sbin/cloudimg-vnc. On Oracle Linux, sudo replaces your PATH with its own secure_path, which does not include /usr/local/sbin, so the image also ships /usr/sbin/cloudimg-vnc as a symlink and sudo cloudimg-vnc works as written. Its subcommands are status, enable [<user>], disable [<user>] and details; <user> defaults to your administrator account.

Confirm the policy and the network side as well:

grep -vE '^#|^$' /etc/tigervnc/vncserver-config-mandatory
sudo ss -tln | awk '$1=="LISTEN"{print $4}' | sort

localhost
securitytypes=tlsvnc,vncauth
0.0.0.0:22
[::]:22

SSH on port 22 is the only service listening.

Step 5: Set your two passwords

First your account password. Run this yourself on the VM and enter the new password twice when prompted:

sudo passwd azureuser

Then your VNC password. Run vncpasswd as yourself, without sudo, enter the password twice, and answer n to the view-only question:

vncpasswd

Password:
Verify:
Would you like to enter a view-only password (y/n)? n
A view-only password is not used

Only the first 8 characters of a VNC password are used, and vncpasswd stores it in ~/.config/tigervnc/passwd with mode 0600. Your SSH access is unaffected: SSH remains key only.

Step 6: Start your VNC desktop

sudo cloudimg-vnc enable

Expected output:

VNC desktop for azureuser enabled on display :1: listening on localhost port 5901 only
from your own machine: ssh -N -L 5901:localhost:5901 azureuser@<vm-ip>
then point a VNC viewer at localhost:5901 and enter azureuser's VNC password

The helper adds :1=azureuser to /etc/tigervnc/vncserver.users, runs systemctl enable --now vncserver@:1.service, waits until port 5901 is listening, and refuses and stops the desktop again if the port is bound anywhere other than localhost. The desktop starts again after a reboot.

If a password is missing it refuses and tells you which one:

refusing to start a VNC desktop for azureuser: the account has no password yet.
The GNOME lock screen and administrator prompts inside the desktop ask for it. Set it first:
  sudo passwd azureuser

refusing to start a VNC desktop for azureuser: no VNC password is set.
As azureuser (without sudo) run:  vncpasswd

Step 7: Connect through an SSH tunnel

On your own workstation, open the tunnel and leave it running:

ssh -N -L 5901:localhost:5901 azureuser@<vm-ip>

Then point your VNC viewer at localhost:5901 (TigerVNC and RealVNC accept localhost:5901; some viewers want the display form localhost:1; on macOS open Screen Sharing and connect to vnc://localhost:5901). Enter your VNC password, and your GNOME desktop opens.

firewalld is active on this image, and the tunnel needs no firewalld rule and no Network Security Group rule: the connection arrives over SSH on port 22 and reaches the VNC server on the machine's own loopback address.

TigerVNC Viewer marks the password dialog "This connection is not secure". It says that because the server has no certificate for the viewer to verify: TigerVNC's TLSVnc security type uses anonymous TLS. Through the SSH tunnel the connection is encrypted and the server is authenticated by SSH, which is why the image only allows VNC over the tunnel.

Step 8: Use the desktop

GNOME opens in the Activities overview. Press Escape for the desktop, or the Super key to return to the overview. The top right system menu offers Restart, Power Off and Log Out. Suspend is deliberately absent, because a suspended Azure virtual machine stops answering while Azure still reports it as running:

The application grid holds the applications that come with the Server with GUI group:

ULN Registration is Oracle's optional tool for registering the machine with the Unbreakable Linux Network, which is for customers who hold a paid Oracle Linux Support subscription. You do not need it: this image already receives its updates from Oracle's public yum repositories, with no registration and no account.

A terminal inside the session behaves exactly as your SSH session does, and your administrator account keeps its sudo rights. The session type is X11, and the VNC server is listening on the loopback addresses only:

To add software, use dnf as on any Oracle Linux machine, for example sudo dnf install -y libreoffice, then open the application from the grid.

Closing your VNC viewer leaves the session running on the VM; connect again and you return to it.

Step 9: Desktops for more users

Each user gets their own display and port. Create the user with a password, have them run vncpasswd, then enable their desktop. The helper assigns the next free display (:2 is port 5902):

sudo useradd -m alice
sudo passwd alice
sudo -u alice -H vncpasswd
sudo cloudimg-vnc enable alice

Alice then tunnels her own port, for example ssh -N -L 5902:localhost:5902 alice@<vm-ip> once her SSH key is in place.

Step 10: Turn VNC off again

sudo cloudimg-vnc disable

VNC desktop for azureuser disabled: display :1 removed, nothing listening on port 5901

This stops the session, disables vncserver@:1.service and removes the mapping, so nothing listens after a reboot. sudo cloudimg-vnc status shows the state at any time.

Step 11: Verify the security posture

Confirm SELinux is enforcing, that SSH is key only, that no account has a password until you set one, and that guest sleep is disabled:

getenforce
sudo sshd -T | grep -E '^(passwordauthentication|kbdinteractiveauthentication) '
sudo passwd -S root | awk '{print $1, $2}'
sudo awk -F: '$2 !~ /^[!*]/ && $2 != "" {n++} END {print "accounts with a password: " n+0}' /etc/shadow
busctl call org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager CanSuspend

Expected output on a new VM (after Step 5 the password count reads 1, your own account):

Enforcing
passwordauthentication no
kbdinteractiveauthentication no
root LK
accounts with a password: 0
s "na"

LK means the root account is locked, and na means logind will not suspend the machine. The sleep policy and the SSH policy are both pinned by drop in files, so a later package update to the main configuration cannot quietly loosen them:

grep -vE '^#|^$' /etc/systemd/sleep.conf.d/20-cloudimg-no-guest-sleep.conf
grep -vE '^#' /etc/ssh/sshd_config.d/60-cloudimg-hardening.conf

[Sleep]
AllowSuspend=no
AllowHibernation=no
AllowSuspendThenHibernate=no
AllowHybridSleep=no
PermitRootLogin prohibit-password
PasswordAuthentication no
KbdInteractiveAuthentication no
ChallengeResponseAuthentication no

Step 12: The graphics device on the Unbreakable Enterprise Kernel

The image boots with module_blacklist=hyperv_fb on the kernel command line, and it matters. Two drivers in the Unbreakable Enterprise Kernel can claim the Hyper-V synthetic video device: the legacy framebuffer driver hyperv_fb and the modern DRM driver hyperv_drm, and whichever registers first wins. On the stock Oracle Linux 9 cloud image hyperv_fb wins, so there is no DRM device at all: the login screen's X server cannot use its modesetting driver, falls back to a 1024x768 framebuffer, and has to run as root instead of as the unprivileged gdm account. With hyperv_fb blocked, hyperv_drm provides the display and the login screen's X server runs without root privileges.

grep -o 'module_blacklist=hyperv_fb' /proc/cmdline
cat /etc/kernel/cmdline
ls /dev/dri

module_blacklist=hyperv_fb
root=/dev/mapper/rootvg-rootlv ro crashkernel=1G-64G:448M,64G-:512M rd.lvm.lv=rootvg/rootlv console=ttyS0 module_blacklist=hyperv_fb
card1

/etc/kernel/cmdline is what gives a kernel you install later the same setting, so a dnf update that brings a new kernel keeps the desktop's graphics device. Do not remove module_blacklist=hyperv_fb from either place. The Red Hat Compatible Kernel does not build hyperv_fb at all, so the setting is harmless if you choose to boot it.

Step 13: Patching and updates

Every available update was applied when this image was built, and dnf-automatic is armed so the machine applies updates on its own schedule:

systemctl is-enabled dnf-automatic.timer
grep -E '^(upgrade_type|download_updates|apply_updates|reboot) ' /etc/dnf/automatic.conf

Expected output:

enabled
upgrade_type = default
download_updates = yes
apply_updates = yes
reboot = never

upgrade_type = default applies every available update rather than only those tagged as security errata, which is how every cloudimg Oracle Linux image is set: a security only policy silently applies nothing for an update that carries no errata metadata.

Check both views of what is pending yourself at any time: whether any package update is available, and whether any security advisory applies to an installed package:

dnf -q check-update >/dev/null 2>&1; echo "check-update exit=$? (0 = nothing pending, 100 = updates available)"
echo "pending security advisories: $(dnf -q updateinfo list --security --available 2>/dev/null | wc -l)"

Automatic updates never restart the machine for you, so check whether a restart is owed after a kernel update and pick your own window:

dnf needs-restarting -r || true

You can always update on your own schedule with sudo dnf -y upgrade, and reboot if a new kernel was installed. To opt out of the automatic updates entirely, run sudo systemctl disable --now dnf-automatic.timer.

GNOME Software may show "Software Updates Ready to Install" on your first login even though dnf reports nothing pending. That notification comes from the firmware updater (fwupd), not from a package: on Azure it offers Microsoft's UEFI Secure Boot revocation list (the "dbx") update published through the Linux Vendor Firmware Service. It is not an operating system package, it is not part of this image, and whether to apply a firmware variable update to your virtual machine is your decision. fwupdmgr get-updates shows exactly what it offers.

Step 14: Networking, the firewall, and services that ship switched off

The Azure Network Security Group is the outer firewall for this image, and firewalld is the host firewall inside it. You do not need to open any port in either for the desktop: it travels inside SSH.

Several daemons are switched off in this image. rpcbind arrives enabled on the Oracle Linux cloud base itself, listening on port 111, and Avahi, CUPS and Bluetooth arrive with or alongside the Server with GUI group; Cockpit is installed but ships disabled. All of them are left installed but disabled, never masked, so the image exposes only port 22 and you can turn any of them back on with a single command:

for u in cockpit.socket avahi-daemon.service cups.service bluetooth.service rpcbind.socket xvnc.socket; do
  echo "$u: $(systemctl is-enabled "$u" 2>/dev/null || true)"
done

cockpit.socket: disabled
avahi-daemon.service: disabled
cups.service: disabled
bluetooth.service: disabled
rpcbind.socket: disabled
xvnc.socket: disabled

To enable any of them, for example the Cockpit web console, run sudo systemctl enable --now cockpit.socket, then open its port in your Network Security Group and in firewalld (sudo firewall-cmd --permanent --add-service=cockpit and sudo firewall-cmd --reload). Do not enable xvnc.socket: it serves a login screen over VNC on port 5900 with no VNC password (-SecurityTypes=None).

firewalld itself is active and enabled, allowing SSH:

systemctl is-active firewalld
sudo firewall-cmd --list-services

active
dhcpv6-client ssh

The network stack is NetworkManager, configured by cloud-init exactly as on Oracle Linux Server.

Step 15: The LVM disk layout

Like every Oracle Linux image on Azure, this image uses an LVM root layout. The root filesystem sits on logical volume rootlv in volume group rootvg, alongside a dedicated crashlv for kernel crash dumps. The /boot and EFI partitions stay plain partitions, which is what the firmware and boot loader need:

findmnt -no SOURCE /
sudo lvs --noheadings -o lv_name,vg_name,lv_size

/dev/mapper/rootvg-rootlv
  crashlv rootvg  15.00g
  rootlv  rootvg <31.90g

Because the root filesystem is on a logical volume, cloud-init does not grow it when you provision a larger operating system disk. After resizing the disk in Azure, find the physical volume with sudo pvs, grow that partition with sudo growpart, run sudo pvresize on it, and extend the root volume and its XFS filesystem in one step with sudo lvextend -r -l +100%FREE /dev/rootvg/rootlv. To add a separate data volume instead, attach an Azure data disk, pvcreate it, vgextend rootvg onto it, then create or extend a logical volume.

Verify what you are running

Three commands answer the three questions that matter: which release this is, that it is a desktop image, and whether VNC is currently on.

cat /etc/oracle-release
systemctl get-default
sudo cloudimg-vnc status

Common Use Cases

• A cloud workstation for enterprise Linux development with a full GNOME desktop, reached through an SSH tunnel
• Running graphical administration and data tools close to your Azure resources
• A RHEL 9 compatible desktop for testing applications certified against RHEL, without a subscription
• Training labs and demonstrations that need a desktop rather than a shell, one desktop per user
• A secure jump desktop that exposes nothing but SSH

Troubleshooting

"Connection refused" on localhost:5901

VNC is off on a fresh VM by design. Run sudo cloudimg-vnc enable first, check the SSH tunnel is still running in its own terminal window, and check the port matches your display (:1 is 5901, :2 is 5902). sudo cloudimg-vnc status shows what is listening.

The viewer says "Authentication failure"

The viewer wants your VNC password, the one you set with vncpasswd, not your account password. Only its first 8 characters count. Set it again with vncpasswd and reconnect; the running desktop does not need restarting.

Connecting directly to the VM's public IP on port 5901 does not work

That is the security design: the VNC server listens on localhost only, and firewalld does not allow the port either. Use the SSH tunnel from Step 7. The localhost setting in /etc/tigervnc/vncserver-config-mandatory also overrides any interface or localhost setting in a user's own ~/.config/tigervnc/config.

The screen is locked and asks for a password

The lock screen wants your account password from sudo passwd <your-user>. If you never set one, the helper would not have started the desktop; if you removed it afterwards, set it again over SSH.

A desktop you start again can also open straight at the lock screen. GNOME remembers, per display, that the previous desktop on that display was locked when it stopped (for example after it locked while idle), and it keeps that promise for the next desktop on the same display while you are still logged in over SSH. Click or press a key and enter your account password.

The desktop does not start for a user

journalctl -u vncserver@:1 shows the service, and the session log is in the user's ~/.local/state/tigervnc/. TigerVNC cannot start a VNC desktop for a user who is already logged into another graphical session on the same machine, so log that session out first.

"This connection is not secure" in TigerVNC Viewer

Expected, and explained in Step 7: the server has no certificate, and the SSH tunnel provides the encryption and server authentication.

Cannot connect via SSH

1. Verify the VM is in Running state in the Azure Portal
2. Check that port 22 is allowed in the Network Security Group
3. Ensure you are using the administrator username you named at create time
4. Verify your SSH key matches the one you supplied at create time. Password login over SSH is disabled by design.

A service is blocked and the logs mention SELinux

SELinux is enforcing, which is the secure default and should stay that way. Denials are recorded in the audit log, so look there rather than in the journal:

sudo ausearch -m AVC -ts recent </dev/null 2>/dev/null || echo "no recent AVC denials"

Most denials on a fresh machine come from software installed into a non standard path. Relabel with sudo restorecon -Rv /path before considering any policy change. vncpasswd already creates ~/.config/tigervnc with the correct vnc_home_t label.

Important Notes

Oracle Linux is free and open source, and Oracle explicitly permits redistribution: the binaries, updates and errata are available at no cost, and an Oracle Linux Support subscription is optional. It is not covered by a single licence: the distribution is a collection of thousands of independently packaged components, each carrying its own terms, predominantly GPL and LGPL, with MIT, BSD, Apache 2.0, MPL and others. The GNOME desktop, GDM and TigerVNC are free software packaged in Oracle's AppStream repository. Every package's terms are readable on the machine with rpm -qi <package> and under /usr/share/licenses/. This image is not Oracle Database and carries no Oracle Database licensing.

Oracle Linux 9 is not an end of life product. It reached general availability in July 2022, Premier Support runs until June 2032 and Extended Support until June 2035. Check Oracle's Lifetime Support Policy for the dates that apply to your deployment.

Oracle Linux is Oracle's name for its distribution and GNOME is a trademark of the GNOME Foundation. Both names are used here nominatively, only to identify the distribution and the desktop environment this image contains. cloudimg is not affiliated with, endorsed by or sponsored by Oracle or the GNOME Foundation.

Support

For assistance with this image, contact cloudimg support:

• Website: www.cloudimg.co.uk
• Product Catalogue: www.cloudimg.co.uk/products
• User Guides: www.cloudimg.co.uk/guides
• SLA: 24 hour response guaranteed