The download link in most Lightworks guides now serves a package that refuses to install on Debian 13 or Ubuntu 26.04. The file is still there, apt still fetches it, and then the dependency solver stops the install dead. Nothing about the error tells you the real cause, which is that the HubSpot mirror those guides point at has been left two releases behind, even though its path says “Latest Version”.
This guide covers how to install Lightworks on Linux the way it actually works today: which download URL carries the current release, how the deb behaves on Ubuntu, Debian and Linux Mint, and what the Flatpak and Snap builds cost you in disk. It also covers the lwks.com account the editor demands on first launch and the export ceiling the free licence puts on your work. The deb went onto Mint 22.3, Ubuntu 26.04, Ubuntu 24.04 and Debian 13 with Lightworks 2025.2 in August 2026, and was run again on the last two with 2026.1 in November 2026, with the Flatpak and Snap on Ubuntu 24.04; the interface walkthrough comes from the Mint machine.
Why the old download link fails on current releases
Lightworks hosts a copy on a HubSpot path named for the latest version, and that is the URL almost every tutorial pastes. It now serves a build two releases old, 2025.1 when we pulled it in November. The vendor’s own CDN has a releases/latest path that is genuinely current, and that is the one to use. The stale build declares a dependency on libgdk-pixbuf2.0-0, a binary package name that no longer exists in Debian 13 or Ubuntu 26.04. Both ship the library as libgdk-pixbuf-2.0-0 instead, with an extra hyphen, and nothing provides the old name.
Ubuntu 24.04 and Linux Mint 22.x still carry a package under the old name, so the same instructions look fine on an older machine and fall over on a fresh one. On noble it is not even the same library, it comes from the gdk-pixbuf-xlib source in universe, but it satisfies the dependency and the install proceeds. Here is how the two builds behave on the four systems we tested. Every row comes from the August run on 2025.2; in November the current-release column was repeated on Ubuntu 24.04 and Debian 13 with 2026.1, whose dependency list is identical, and the Debian 13 failure was reproduced with the stale file:
| System | apt version | Package behind the “latest” link | Current release from cdn.lwks.com |
|---|---|---|---|
| Linux Mint 22.3 (noble base) | 2.8.3 | Installs | Installs, upgrades cleanly over it |
| Ubuntu 24.04.4 LTS | 2.8.3 | Installs | Installs |
| Debian 13 | 3.0.3 | Fails, unmet libgdk-pixbuf2.0-0 | Installs |
| Ubuntu 26.04 LTS | 3.2.0 | Fails, unmet libgdk-pixbuf2.0-0 | Installs |
The failure looks like this on Debian 13, where apt 3 heads the list with Unsatisfied dependencies:, prints its new solver trace and exits 100. Ubuntu 26.04 prints the same block. Reach for apt-get instead and the same failure is headed The following packages have unmet dependencies:, which is worth knowing if you are searching for the message:
The current release fixed the package name and picked up two new dependencies, libpulse0 and libsndio7.0. We resolved its full dependency list against the Debian 13, Ubuntu 24.04 and Ubuntu 26.04 archives and every entry is satisfiable, so the fix is real rather than a lucky local state.
Download the current Lightworks release
The deb and the rpm both sit behind a version-free path on the vendor CDN, which is what you want in a bookmark. Debian gives you wget in its default install but leaves curl optional, and a genuinely minimal install has neither, so pull it in first if the command is missing:
sudo apt update
sudo apt install -y curl
curl -LO https://cdn.lwks.com/releases/latest/lightworks_linux_deb.debThe Flatpak and Snap bundles are not published under that path, and their file names changed with 2026.1, so any guide that builds the URL from a release and build number now fetches an old bundle. The Lightworks downloads page fills its buttons from a small JSON manifest on the same CDN, and reading that manifest is the reliable way to find the current files. Install jq and ask it for the stable release:
sudo apt install -y jq
curl -s https://cdn.lwks.com/releases/latest.json | jq -r '.channels.stable.version, .channels.stable.downloads["linux-flatpak"].url, .channels.stable.downloads["linux-snap"].url'In November 2026 that printed the 2026.1.0 release and its two bundle URLs. The same manifest carries a beta channel, so keep the stable key in the filter unless you want pre-release builds:
2026.1.0
https://cdn.lwks.com/releases/2026.1.0/lightworks_2026.1.0.flatpak
https://cdn.lwks.com/releases/2026.1.0/lightworks_2026.1.0.snapBefore installing anything, read the version out of the package you just downloaded. This one check is what separates a working install from the dependency wall above:
dpkg-deb -f lightworks_linux_deb.deb Version DependsThe Depends line should name libgdk-pixbuf-2.0-0 with the hyphen before the 2. If you see libgdk-pixbuf2.0-0 without it, you downloaded the stale build and apt will reject it on any current release:
Version: 2026.1.0
Depends: ocl-icd-libopencl1, libtwolame0, libvdpau1 (>= 1.3), libva-drm2 (>= 2.7.0), libc6 (>= 2.17), libcairo2 (>= 1.10.0), libgcc1 (>= 1:4.1.1), libgdk-pixbuf-2.0-0 (>= 2.22.0), libgl1-mesa-glx | libgl1, libglib2.0-0 (>= 2.64.0) | libglib2.0-0t64 (>= 2.80.0), libglu1-mesa | libglu1, libgtk-3-0 (>= 3.0.0) | libgtk-3-0t64 (>= 3.0.0), libpango-1.0-0 (>= 1.18.0), libstdc++6 (>= 4.6), libjack-jackd2-0, libuuid1, libasound2, libpulse0, libsndio7.0, libc++1Two things in that list are worth knowing. The GLib and GTK entries each list a pre-time_t name and a t64 name, and on Ubuntu 24.04, Ubuntu 26.04 and Debian 13 it is always the t64 package that satisfies them; the older alternative is there for releases from before that transition. Several other entries resolve through virtual names rather than real packages, so libgcc1 comes from libgcc-s1 and libasound2 from libasound2t64.
On the Ubuntu 24.04 VM the full check looked like this, with the size and checksum of the file we tested so you can compare yours against it:
A different checksum is not a problem by itself, because the vendor replaces the file behind that path on every release. The version and the hyphenated pixbuf name are the two things that matter.
Install Lightworks on Linux Mint and Ubuntu
Hand the local file to apt with a path, not a bare filename, so it resolves dependencies from the archive instead of treating the argument as a package name:
sudo apt install ./lightworks_linux_deb.debHow much comes down with it depends entirely on what the machine already has. A Mint 22.3 Cinnamon desktop needs only five new packages, four of them the LLVM C++ runtime, because the GTK, Mesa, JACK and sndio stacks are already there. A headless Ubuntu 24.04 server pulls the whole GTK 3, Mesa and Adwaita chain instead: 115 new packages, an 81.1 MB download and 904 MB of extra disk. apt asks you to confirm before it fetches anything, so add -y if you want it unattended. The lines around the Lightworks step look like this:
Setting up libgtk-3-0t64:amd64 (3.24.41-4ubuntu1.3) ...
Setting up at-spi2-core (2.52.0-1build1) ...
Setting up lightworks (2026.1.0) ...
gtk-update-icon-cache: Cache file created successfully.
Processing triggers for libc-bin (2.39-0ubuntu8.7) ...
Setting up libgtk-3-bin (3.24.41-4ubuntu1.3) ...
Processing triggers for libgdk-pixbuf-2.0-0:amd64 (2.42.10+dfsg-3ubuntu3.3) ...Confirm what landed and how much space it took. The editor itself is a single large tree under /usr/lib:
dpkg -l lightworks
du -sh /usr/lib/lightworks
cat /usr/bin/lightworksOn 2026.1, 429 MB of that tree is the application, with another 59 MB of shipped defaults under /usr/share/lightworks, which together account for the Installed-Size the control file advertises. /usr/bin/lightworks turns out to be a four-line shell wrapper rather than the binary. Reading it explains a lot about how the editor behaves on a modern desktop:
#!/bin/sh
#Launch the app
LD_PRELOAD=libmimalloc.so LD_LIBRARY_PATH=/usr/lib/lightworks GDK_BACKEND=x11 GDK_SCALE=1 /usr/lib/lightworks/ntcardvtGDK_BACKEND=x11 is forced, so on a Wayland session Lightworks runs through XWayland whether you asked for that or not. The real process is called ntcardvt, which matters when you go looking for it in ps or need to kill a hung instance. Our Mint test machine had no GPU at all and the editor still started on Mesa llvmpipe with an OpenGL 4.5 compatibility profile, so software rendering is enough to get the interface up even if it is no way to grade footage.
The same three checks on the Ubuntu 24.04 VM, plus the sndio library files the next part is about:
Two things happen at install time that are worth knowing about before you put this on a shared machine. Read the package’s own post-install script:
dpkg-deb --info lightworks_linux_deb.deb postinstIt relaxes the permissions on two directories it ships, and on some systems it plants a symlink in a directory that belongs to the distribution’s own audio library. The 2026.1 script also clears launcher files left by older installs, refreshes the desktop and icon caches, and records how Lightworks was installed:
#!/bin/sh
allusers=/usr/share/lightworks
set -e
# May need to be able to write to the following locations :
chmod a+rw $allusers/Preferences
chmod a+rw "$allusers/Audio Mixes"
# Symlink libsndio.so.7.2 → libsndio.so.7.1 if needed
LIBDIR="/usr/lib/x86_64-linux-gnu"
if [ -e "$LIBDIR/libsndio.so.7.2" ] && [ ! -e "$LIBDIR/libsndio.so.7.1" ]; then
ln -s "libsndio.so.7.2" "$LIBDIR/libsndio.so.7.1"
fi
# Remove stale files from previous installs that used different names
rm -f /usr/share/applications/lightworks.desktop
rm -f /usr/share/icons/hicolor/128x128/apps/lightworks.png
# Refresh the desktop and icon caches so the app shows up in the launcher
if command -v update-desktop-database >/dev/null 2>&1; then
update-desktop-database /usr/share/applications || true
fi
if command -v gtk-update-icon-cache >/dev/null 2>&1; then
gtk-update-icon-cache -f -t /usr/share/icons/hicolor || true
fi
echo "deb" > $allusers/install_typeBoth directories end up as drwxrwxrwx. They hold shipped defaults rather than personal settings, the keyboard maps, layouts, language files and the example audio mixes that every account on the box loads, so the risk is that any local user can tamper with files the others read. Your own preferences live under ~/Lightworks and are untouched by this.
The symlink is stranger, and it is worth knowing it does nothing. Two files in the package want sndio and both ask for libsndio.so.7: the bundled libportaudio.so.2.0.0 names it as a linked dependency, and ffmpeg.lwd carries an SDL audio backend that opens it by name at runtime. Every one of these distributions already provides that soname. Nothing anywhere in the tree references the .7.1 name the postinst creates, and the branch only fires on Ubuntu 24.04 and Mint, whose sndio is .so.7.2; Debian 13 and Ubuntu 26.04 ship .so.7.3 and never take it. Read together with the stray Provides: libsndio7.1 in the control file, both look like leftovers from the vendor’s build host. 2026.1 added a postrm, but all it does is delete install_type and refresh the caches again, so on the releases where the symlink does get made it survives a purge, and sudo rm /usr/lib/x86_64-linux-gnu/libsndio.so.7.1 is the way to take it back out.
Install Lightworks on Debian 13
Debian needs no extra repository and no backports. The same deb and the same command work, and every dependency resolves out of main. If you skipped the download section, fetch the file first, installing curl on the way because a minimal Debian does not have it:
sudo apt update
sudo apt install -y curl
curl -LO https://cdn.lwks.com/releases/latest/lightworks_linux_deb.deb
sudo apt install ./lightworks_linux_deb.debThe rejection shown near the top came from a Debian 13 box, and it names only the one dependency that cannot be satisfied. On a machine missing more of them apt walks a longer chain, because it lists every dependency it could not schedule, so a longer block is host state rather than a different fault. The solver note is a real difference between releases though. Debian ships apt 3.0, which says “conflicting decisions” where apt 3.2 on Ubuntu 26.04 says “conflicting assignments”. Same cause, and both exit 100. With the current build the install goes straight through on a Debian 13 cloud image:
That was 144 new packages, a 94.3 MB download and 952 MB of disk, a little more than Ubuntu because the cloud image starts with less. The two lines to look for are the Lightworks step and the pixbuf trigger:
Setting up lightworks (2026.1.0) ...
Processing triggers for libgdk-pixbuf-2.0-0:amd64 (2.42.12+dfsg-4+deb13u1) ...The effects pipeline leans on OpenCL and NVIDIA Cg, and the package carries both (libOpenCL.so.1.2, libCg.so and libCgGL.so all ship inside /usr/lib/lightworks), so the piece you supply is the GPU driver. On Debian the proprietary driver packages (nvidia-driver, nvidia-kernel-dkms) sit in non-free, the GSP firmware in non-free-firmware and the open kernel module in contrib, and since a stock installation enables only main and non-free-firmware, you add contrib and non-free to the sources before any of it is installable.
Install the Flatpak build
Lightworks publishes a Flatpak bundle alongside the deb, which is the cleanest route if you would rather not scatter 429 MB of vendor libraries through /usr/lib. The bundle is not on Flathub, so you download it and install the file, but it still needs Flathub configured because that is where its runtime comes from. If you are weighing this against the deb, our breakdown of how Snap, Flatpak and AppImage differ covers the trade-offs.
sudo apt install -y flatpak jq
sudo flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo
LW_FLATPAK=$(curl -s https://cdn.lwks.com/releases/latest.json | jq -r '.channels.stable.downloads["linux-flatpak"].url')
curl -LO "$LW_FLATPAK"
sudo flatpak install -y "./$(basename "$LW_FLATPAK")"On the Ubuntu 24.04 VM that fetched lightworks_2026.1.0.flatpak, about 132 MB, and the install ended by pulling the runtime pieces before the app itself. Watch what it drags in. List what Flatpak now holds:
flatpak list --columns=application,version,branch,sizeThe app itself is 521.5 MB installed, and the freedesktop runtime plus the GL extensions add roughly 1.6 GB on a machine that has never used Flatpak before:
com.lwks.Lightworks stable 521.5 MB
org.freedesktop.Platform freedesktop-sdk-25.08.19 25.08 670.7 MB
org.freedesktop.Platform.GL.default 26.2.5 25.08 462.3 MB
org.freedesktop.Platform.GL.default 26.2.5 25.08-extra 462.3 MB
org.freedesktop.Platform.codecs-extra 25.08-extra 43.4 MBLaunch it by application ID rather than by command name. Flatpak does export a wrapper, but it is named after the app ID and sits in /var/lib/flatpak/exports/bin, which is not on PATH by default, so there is no lightworks command from this route:
flatpak run com.lwks.LightworksThe app came from a downloaded bundle rather than a Flathub listing, and flatpak info reports its origin as lightworks-origin rather than flathub. Moving to a newer release means fetching the next bundle. Once the manifest names a newer file, remove the app with sudo flatpak uninstall -y com.lwks.Lightworks (the runtimes stay, so the reinstall is quick) and run the three download and install lines again.
Install the Snap build
The Snap is a local file too, not a store publication, so it needs both --classic and --dangerous. The first flag grants it full filesystem access, the second tells snapd to accept an unsigned local snap. At about 223 MB for 2026.1 it is the largest of the three artefacts. Ubuntu has snapd already; Debian does not install it by default, and Linux Mint actively blocks it with an apt pin:
cat /etc/apt/preferences.d/nosnap.prefMint has shipped that file since Mint 20, and it pins the package below the installable threshold:
Package: snapd
Pin: release a=*
Pin-Priority: -10Leave it in place and sudo apt install snapd answers E: Package 'snapd' has no installation candidate. Move it aside, refresh the lists, and snapd installs like any other package. Our walkthrough of using snap on Linux Mint covers the policy behind it:
sudo mv /etc/apt/preferences.d/nosnap.pref ~/nosnap.pref.bak
sudo apt update
sudo apt install -y snapdWith snapd in place, sideload the bundle:
sudo apt install -y jq
LW_SNAP=$(curl -s https://cdn.lwks.com/releases/latest.json | jq -r '.channels.stable.downloads["linux-snap"].url')
curl -LO "$LW_SNAP"
sudo snap install "./$(basename "$LW_SNAP")" --classic --dangeroussnapd restarts itself partway through on a fresh system, which produces a waiting line before the install confirms. This is the 2026.1 run on Ubuntu 24.04:
2026-11-04T19:16:44Z INFO Waiting for automatic snapd restart...
lightworks 2026.1.0 installedBefore trusting it on a workstation, read what the 2026.1 snap declares about itself. Its meta/snap.yaml and snap list lightworks on the Ubuntu 24.04 VM gave these values:
base: core22, an older runtime than Ubuntu 24.04 itselfgrade: devel, so it was never meant for the stable store channelconfinement: classic, which is why--classicis required- revision
x1, the marker snapd gives any sideloaded file
It launches from /snap/bin/lightworks; if you only just installed snapd on Debian or Mint, log out and back in first so /snap/bin is on your PATH. The 2026.1 snap is still built on the core22 base, and when we ran the 2025.2 snap on Mint it printed one warning on the way up because of that base, so the host’s GVFS module cannot load inside it: version `GLIBC_2.38' not found (required by /usr/lib/x86_64-linux-gnu/gio/modules/libgvfsdbus.so). The editor still opens; the practical cost is that the sandbox does not get the desktop’s GVFS mounts. Because the snap is sideloaded it carries revision x1 and will never auto-update, so you are back to downloading files by hand when the next build lands. Its own metadata marks it grade: devel, and there is no lightworks snap in the store at all, which is why this is a file you download rather than something you install by name. Our guide to choosing between snap, flatpak and apt on Ubuntu goes further into when that matters.
First launch and the lwks.com account requirement
Start it from the applications menu or by running lightworks in a terminal. The first run opens a short numbered wizard, and step one is a language list with English preselected:
The second screen is the one that stops people. Lightworks will not open the editor at all until you sign in to an lwks.com account, and it says so in as many words. There is no offline mode and no skip button:
Create the account in a browser rather than in the app. The wizard offers to make one for you, but that branch never advanced past this screen across four attempts driven by scripted clicks, while the sign-in branch moved on first time with the same method. Register at app.lwks.com/sign-up, which wants an email address and a password containing at least one special character, then come back to the wizard, pick “I already have an account” and sign in there.
A successful sign-in replaces the form with your licence table. This is where the free tier shows its shape: the entitlement is called Free, it is active, and it carries a 90 day renewal, so the free licence is not a one-off activation you can walk away from offline.
After that the wizard asks whether you approve anonymised usage data collection, and Next stays greyed out until you pick Approve or Reject. Rejecting it does not restrict anything in the editor. If the wizard ever gets stuck, close Lightworks and start it again, because the sign-in is remembered and it comes back on the project browser. An unclean exit adds one more prompt on the next start, offering to upload crash logs, and answering No is enough to get past it.
Create a project and load a clip
The project browser is the real front door. It lists local projects, offers to restore an archived one, and prints the exact build in the footer, which is the fastest way to confirm which release you are actually running:
Click Create new project, give it a name and confirm. The Details tab asks only for a name and optional notes, with format settings tucked behind an Advanced tab. The sequence it creates reports itself as 1080p 16:9 in Rec. 709 in the Sequences list. Projects live under a Lightworks directory in your home folder, and a lock file named .Lightworks.thereCanBeOnlyOne next to it is what stops a second instance from starting.
Use Import clips to bring media in. The file browser opens on your home directory with shortcuts for Videos, Pictures and Music, and it also lists Box, Dropbox, Google Drive, Google Photos and OneDrive alongside Pexels and Pond5 stock sources. Select a file, import it, then drag its thumbnail out of the clips list onto the Video 1 track. Note the list, not a bin: imports land under Collections in Project contents, and Bins starts out empty. A 1080p H.264 clip lands as linked video and audio with a waveform drawn, and the viewer shows the frame under the playhead:
That is a working edit session on Linux with no proprietary driver, no PPA and no build step. The FX Settings panel on the right is live from this point: framing, colour correction with balance, RGB, HSV and curves tabs, plus a 3D transform. If you still need to capture the footage in the first place, OBS Studio on Ubuntu and Debian feeds this workflow well.
What the free licence limits
Editing is not where the free tier bites. Exporting is. On the 2025.2 build we walked through, the EXPORT tab on a 1080p sequence held the resolution field at 720p, and the destination presets are weighted towards uploading straight to YouTube:
The Lightworks pricing page now lists Free at up to 1080p, Create at up to 4K and Pro at up to 8K, so check the resolution field on your own build before you plan a delivery around the 720p ceiling in that capture. Either way, that single limit decides whether Lightworks is the right tool for you. Note also that the panel opens on the YouTube destination, which greys out Start until you sign in to YouTube; switch Format to a local file preset if you just want a file on disk. Timeline editing, automatic saving, transitions and the simpler effects are all in the free tier, so it is a genuine editor rather than a demo, but 4K delivery needs a paid licence. If you only ever need to change container or codec, converting video formats with ffmpeg costs nothing and skips the editor entirely. If you are comparing paid options, we have a look at how Lightworks and Filmora handle effects. Running Fedora instead? Our guide to installing Lightworks on Fedora uses the vendor rpm, which bundles its own Cg and OpenCL libraries, as the deb does, and FFmpeg too, so it needs neither RPM Fusion nor a separate libCg package.
Errors you will actually hit
Error: “Depends: libgdk-pixbuf2.0-0 (>= 2.22.0) but it is not installable”
You downloaded the stale build from the HubSpot mirror on a system that no longer carries that package name. Nothing on your machine is broken and installing the old library is not the fix. Delete the file, fetch the deb from the releases/latest path shown earlier, and check dpkg-deb -f file.deb Depends before you run apt again.
Error: “dependency problems” after forcing the install with dpkg
When apt refuses, the tempting next move is dpkg on its own, and it appears to work. It does not:
sudo dpkg -i lightworks_linux_deb.debdpkg unpacks the whole package, 505 MB under /usr/lib/lightworks alone on our Debian 13 box with the stale build, then fails at the configure step and leaves it half installed:
dpkg: error processing package lightworks (--install):
dependency problems - leaving unconfigured
Errors were encountered while processing:
lightworksCheck the state flags and you will see iU, meaning unpacked but not configured, which is a package that consumes the disk without giving you a usable editor. On our Debian 13 box apt put the cost of that half-install at 584 MB, all of it Lightworks itself, since dpkg never fetched a single dependency. Note what the recovery actually does, because it removes Lightworks rather than repairing it:
dpkg -l lightworks
sudo apt -f installWe ran that whole sequence on Debian 13 with the stale build. dpkg lists the missing libraries, the package sits at iU, and apt -f install resolves it by scheduling Lightworks for removal:
Once that finishes, /usr/lib/lightworks is gone and you are back where you started. The only fix that leaves you with a working editor is the one from the previous error: fetch the current deb and let apt install it.
“Using default folder :(” then nothing appears
That log line is normal and appears on every start, even a healthy one. It only signals a problem when it is followed by Aborted (core dumped), which is what happens if you launch Lightworks over SSH or in any session without a display. The editor needs a real desktop session; there is no headless or CLI render mode to fall back on.
A second copy starts, prints one line and vanishes
Lightworks allows exactly one running copy. Launch it again while an instance is up and the second command prints the default-folder line, exits with status 0 and opens nothing at all. No error, no dialog, no window. Check for a live process before you conclude the install is broken:
pgrep -x ntcardvtThe single-instance guard is a zero-byte file called .Lightworks.thereCanBeOnlyOne in your home directory, and it stays there between runs, so finding it is not evidence of a crash. Deleting it while a copy is alive gets you two instances fighting over the same project directory, which is a good way to lose an edit.
Remove Lightworks and reclaim the disk
Between the vendor tree and its dependency chain, an install of Lightworks is close to a gigabyte, so removing it properly is worth the extra flag. Purge takes the package and its configuration, and autoremove clears the libraries nothing else needs:
sudo apt purge --autoremove lightworksOn our Ubuntu 24.04 box that pair removed 115 packages, Lightworks and the 114 dependencies it had pulled in, and took the root filesystem from 3.1 GB used down to 2.2 GB, with /usr/lib/lightworks gone afterwards. The Flatpak and Snap builds come out separately, and the Flatpak leaves its runtimes behind unless you ask for them too:
sudo flatpak uninstall -y com.lwks.Lightworks
sudo flatpak uninstall -y --unused
sudo snap remove lightworksNone of that touches your work. The Lightworks directory in your home folder survives, and so does the single-instance lock file, so a reinstall picks up where you left off. Your footage was never copied into the project either, at least not on the default import setting, which links to the files where they already sit. That also means moving or deleting the originals breaks the project. Choose Copy Local or Transcode at import time instead and Lightworks takes its own copy.
