
noVNC
Browser-based VNC access that runs well in modern desktop and mobile browsers
Overview
noVNC is both a VNC client JavaScript library and an application built on top of that library. It runs well in any modern browser, including mobile browsers on iOS and Android.
It is a browser-based VNC client, not a native desktop viewer—access happens through your web browser rather than a standalone app.
Key features
noVNC focuses on simple, browser-based VNC access with QuickBox-managed services and paths.
Browser-first VNC
VNC client JavaScript library that runs in modern browsers, including mobile
Per-user services
Systemd units vnc@username.service and novnc@username.service are created per user
Reverse-proxied paths
nginx locations /username/vnc and /username/websockify map to /srv/novnc and 127.0.0.1:port
Base ports
Base ports are 6080 (web) and 5901 (VNC daemon) with auto-generated flags enabled
When to use it
Choose noVNC when you want browser-based VNC access that QuickBox exposes through user-scoped paths.
You want
- Need VNC access that works in modern desktop and mobile browsers
- Want user-scoped web paths like
/username/vncand/username/websockify - Prefer per-user systemd services for VNC and websockify
QuickBox provides
- QuickBox provisions
vnc@username.serviceandnovnc@username.serviceper user - nginx serves
/username/vncfrom/srv/novncand proxies/username/websockify - Dashboard Service Control surfaces live port and service state for noVNC
Installation
Install from the Dashboard
Open App Dashboard → Package Management (/dashboard?mode=packages), find noVNC in the Remote Access category (or search), and click Install. The dashboard streams the install log live and the live noVNC port and status appear in your Application Control panel when it finishes. Reinstall, Update, and Remove are on the same panel.
noVNC pulls a full Xfce desktop, an X server stack, and firefox-esr, so its install takes longer than most apps. What you see is gated by your account: admins manage any user’s apps, regular users manage their own. See App Management for the full flow.
Install from the CLI (automation)
The CLI runs the same script and suits automation:
qb install novnc -u username
qb reinstall novnc -u username
qb update novnc -u username
qb remove novnc -u usernameCLI Options
-u, --usernameRequiredTarget QuickBox username for install, reinstall, update, and remove actions
Full flag reference: CLI Reference.
Access and authentication
URL / route
- Per-user access URL:
https://host/username/vnc/vnc.html?resize=remote&host=host&path=username/websockify - nginx serves
/username/vncfrom/srv/novncand proxies/username/websockifyto127.0.0.1:port. - When a system-level
novnc.serviceexists, the Dashboard link resolves tohttps://host/vnc.
Login / credentials / tokens
- QuickBox decrypts the QuickBox user password and applies it with
vncpasswdduring install. - HTTP Basic auth for
/username/vncuses/etc/htpasswd.d/htpasswd.username.
Security notes
QuickBox adds iptables rules to accept only localhost traffic on the VNC daemon port and drop other traffic. Access is intended through the nginx paths instead of direct VNC port access.
Change your noVNC password
Your noVNC desktop uses a dedicated VNC password that is separate from your QuickBox account password. QuickBox sets a default derived from your account password at install, and you can change it at any time. This password is stored on its own and survives a reinstall — reinstalling noVNC does not reset a password you set yourself.
Change it from the Dashboard (recommended)
- Open the App Dashboard (
/dashboard— the default view that lists your installed apps; this is the Application Control view, where you manage an app after install rather than install or remove it) and find your installed noVNC row. - Expand the row and open the API & Secrets panel.
- In the New password field, type the password you want and click Save.
- To check the password already in effect, click the eye toggle in the Current field to reveal it.
You can only reveal your own noVNC password — the reveal control never exposes another user’s password, even for an admin.
noVNC uses only the first 8 characters of the password, so anything past the eighth character is ignored when you connect. Saving also restarts noVNC and disconnects any active desktop session, so reconnect with the new password afterward.
Change it from the CLI
Run the noVNC password command for your user:
qb user vncpasswd -u usernameThe command prompts you for the new password twice (your input is hidden), confirms that the two entries match, applies it, and restarts the noVNC service so the new password takes effect immediately. An admin can set another user’s noVNC password, but only the owner can reveal a stored password.
Configuration and files
Common tasks
- Start services:
systemctl start vnc@username.servicethensystemctl start novnc@username.service - Stop services:
systemctl stop novnc@username.serviceandsystemctl stop vnc@username.service - Restart services:
systemctl restart novnc@username.serviceorsystemctl restart vnc@username.service - View live port and status: Dashboard Service Control shows the current noVNC port and status
- Update or remove: use
qb update novnc -u usernameorqb remove novnc -u username
FAQ
6080 and a base VNC daemon port of 5901, with auto-generated flags enabled. The Dashboard Service Control view shows the current assigned noVNC port./username/vnc/vnc.html?resize=remote&host=host&path=username/websockify and maps the nginx locations /username/vnc and /username/websockify to the noVNC client and websockify bridge.vncpasswd based on the stored QuickBox user password, and nginx protects /username/vnc using HTTP Basic auth from /etc/htpasswd.d/htpasswd.username.firefox-esr. If the server has apt-listbugs installed, it pauses the apt transaction to show bug reports for those packages and waits for confirmation; when nothing answers, apt exits with a non-zero status (often error code 10) and the install reports a dependency failure. Remove the prompt tool with apt-get -y purge apt-listbugs, then run apt-get update and apt-get -y --fix-broken install, and re-run qb install novnc -u username./username/vnc, which is reverse-proxied through nginx and the websockify bridge.Best practices
Do
- Use the Dashboard Service Control view to confirm the active port and service state for noVNC.
- Keep
/home/username/.vnc/xstartupexecutable so Xfce launches with autocutsel and startxfce4. - Use the
/username/vncpath protected by HTTP Basic auth for browser access.
Don't
- Do not expect direct access to the VNC daemon port; iptables drops non-local traffic to that port.
- Do not delete
/etc/htpasswd.d/htpasswd.usernameif you rely on HTTP Basic auth for/username/vnc.
Troubleshooting
noVNC install fails or hangs on a dependency prompt
noVNC pulls in one of the heaviest dependency sets of any QuickBox app: it installs a full Xfce desktop, an X server stack, TightVNC, and firefox-esr. On some servers apt stops on an interactive prompt while pulling these packages, which makes qb install novnc appear to hang or fail.
This happens when the apt-listbugs package is present on the server. While noVNC installs firefox-esr and the Xfce/X11 packages, apt-listbugs intercepts the transaction, prints any known bug reports for those packages, and waits for you to confirm. If nothing answers the prompt, the apt run exits non-zero (commonly error code 10) and the noVNC install reports a dependency failure.
- Remove the interactive bug-prompt tool so apt can complete non-interactively:
apt-get -y purge apt-listbugs - Refresh the package lists and finish the pending package work:
apt-get update apt-get -y --fix-broken install - Re-run the install:
qb install novnc -u username
If you prefer to keep apt-listbugs, you can instead pre-install the dependency set in a session where you can answer the prompt, then run qb install novnc.
The Xfce + X server + firefox-esr dependency set requires up-to-date package lists. A stale or partially-updated apt cache can leave the install unable to resolve firefox-esr, tightvncserver, or the xserver-xorg packages.
Fix: refresh apt and clear any broken state, then reinstall:
apt-get update
apt-get -y --fix-broken install
qb reinstall novnc -u usernameAfter install — common access failures
Checks: Confirm vnc@username.service is running and /home/username/.vnc/xstartup exists and is executable. The xstartup script launches the Xfce session — if the service is stopped, or xstartup is missing or not executable, the VNC server never brings a desktop up.
systemctl status vnc@username.service
ls -l /home/username/.vnc/xstartupA grey stippled background with nothing on it except an X mouse cursor is different from the case above: the VNC service is running, xstartup exists and is executable, but the Xfce desktop session did not paint. The X server came up; the desktop on top of it did not.
Read the session log to see why the desktop stopped. The log is named after the server hostname and display :1:
cat ~/.vnc/$(hostname):1.logConfirm the Xfce packages are intact:
apt-get -y --fix-broken installFix (recommended): update noVNC so it re-applies QuickBox’s current session startup, which launches the Xfce desktop on its own D-Bus session so it paints reliably:
qb update novnc -u usernameIf updating does not clear it, reinstall with qb reinstall novnc -u username. Both re-apply the hardened session startup and neither resets your noVNC password. Hand-editing /home/username/.vnc/xstartup is only a fallback if you cannot update or reinstall.
This most often shows up after installing another remote-desktop app such as X2Go on the same server — see Running noVNC alongside X2Go below.
Checks: Confirm novnc@username.service (the websockify proxy) is active and that /etc/nginx/conf.d/username.vnc.conf points to the assigned web port. The websockify proxy bridges the browser WebSocket to the VNC server — if it is stopped, the page loads but the connection is refused.
systemctl status novnc@username.service
systemctl restart novnc@username.serviceThis is expected. QuickBox adds iptables rules that accept VNC daemon-port traffic only from localhost and drop everything else. Connect through the browser path /username/vnc (which goes through the websockify proxy and nginx), not by pointing a desktop VNC viewer at the daemon port.
The /username/vnc route is protected by nginx HTTP Basic auth using /etc/htpasswd.d/htpasswd.username. A second password prompt comes from the VNC server itself — a dedicated noVNC password that defaults to your QuickBox account password at install. If Basic auth keeps failing, confirm the htpasswd file exists for your user. If the VNC password is rejected, set a new one from the Dashboard (App Dashboard → the noVNC row → API & Secrets) or with qb user vncpasswd -u username — see Change your noVNC password. A reinstall does not reset this password, since it is stored separately and survives reinstall.
Running noVNC alongside X2Go
noVNC and X2Go coexist fine on one server. X2Go stands up its own per-user D-Bus session, and on an older noVNC install that stray session bus could attach the noVNC desktop to the wrong bus and leave it blank — the grey-screen symptom above. QuickBox’s current session startup launches noVNC’s Xfce desktop on its own isolated D-Bus, so the two run side by side without interfering.
If your noVNC desktop went blank after installing X2Go, update (or reinstall) noVNC to apply the fix — X2Go itself needs no change:
qb update novnc -u usernameResources
Resources
Join the Community
Media server operators sharing configs, getting support, and shaping the future of QuickBox Pro.