Obsidian window has no system icon (generic icon) on Linux — _NET_WM_ICON not set

rbcn2000 · August 17, 2026, 4:35am

Obsidian window has no system icon (generic icon) on Linux — _NET_WM_ICON not set

There’s an existing report of the same symptom that got auto-locked after 90 days without a resolution: System icon not set on Linux: ttps://forum.obsidian.md/t/system-icon-not-set-on-linux/94655
Opening a new topic with the root cause identified, since I can no longer reply there.

I can confirm and reproduce this on Linux Mint 22.x / Xfce 4.18, Obsidian 1.13.7 (official AppImage from obsidianmd/obsidian-releases).

Symptom: The Obsidian window shows a generic/blank window icon in the taskbar/window list, even though the app itself launches and runs fine, and the .desktop launcher menu entry shows the correct icon.

Root cause (verified with xprop and libwnck): Obsidian’s window never sets _NET_WM_ICON (the EWMH property that carries the actual icon pixel data), nor a legacy WM_HINTS icon pixmap:

$ xprop -id <obsidian-window-id>
...
WM_CLASS(STRING) = "md.obsidian", "md.Obsidian"
WM_NAME(UTF8_STRING) = "..."
# no _NET_WM_ICON property present at all
# no WM_HINTS icon_pixmap present

Checking the window via libwnck (used by Xfce’s panel/tasklist, and by many other WMs) confirms it’s treated as a fallback icon:

w.get_icon_is_fallback()  # -> True

libwnck only derives a window’s icon from _NET_WM_ICON / WM_HINTS set by the window itself — when neither is present, it does not consult the application’s .desktop file (Icon= / StartupWMClass=) at all, and falls straight through to a built-in generic icon. (This is different from GNOME Shell, which does its own .desktop-based window-to-app matching and can substitute a proper icon even without _NET_WM_ICON — which is likely why some users on GNOME don’t see this.)

As a proof of concept, manually injecting a _NET_WM_ICON property onto the already-running Obsidian window (small Xlib script, no changes to Obsidian itself) immediately fixes the taskbar icon:

w.get_icon_is_fallback()  # -> False, after injecting _NET_WM_ICON

This confirms the generic icon is solely due to the missing _NET_WM_ICON/WM_HINTS icon on Obsidian’s own window — not a .desktop file or window-manager misconfiguration on the user’s side. The app’s own .desktop/AppImage metadata (WM_CLASS, bundled icon resources) are all correct and consistent.

Suggested fix: When creating the BrowserWindow on Linux, pass an icon option (pointing to a PNG already bundled in the AppImage under usr/share/icons/hicolor/*/apps/) so Electron/Chromium sets _NET_WM_ICON on the window. This is standard practice for Electron apps on Linux, and would fix the icon across all window managers that don’t do .desktop-based icon substitution (Xfce, i3, sway, etc.), not just this one report.

Debug info:

Reproduced in the default vault (with plugins) and also in a Sandbox Vault (Restricted mode on, no community plugins) — same generic icon in both, confirming this is unrelated to any plugin:

SYSTEM INFO:
    Obsidian version: 1.13.7
    Installer version: 1.13.4
    Operating system: #137-Ubuntu SMP PREEMPT_DYNAMIC Fri Jul 17 20:28:23 UTC 2026 6.8.0-137-generic
    Login status: not logged in
    Language: ja
    Insider build toggle: off
    Live preview: on
    Base theme: adapt to system
    Community theme: none
    Snippets enabled: 0
    Restricted mode: on

RECOMMENDATIONS:
    none

WhiteNoise · August 17, 2026, 2:10pm

_NET_WM_ICON is an X11 thing. Obsidian runs on wayland by default (if available). There is no wayland equivalent to _NET_WM_ICON. So you do need to set up your .desktop correctly.

If you are using AppImage directly, you need to create a .desktop file and place it where your window manager can find it (maybe ~/.local/share/applications/).

I suggest you:

Download the latest AppImage from our website (1.13.7)
Create a .desktop file named md.obsidian.Obsidian.desktop pointing to your AppImage and with StartupWMClass=md.obsidian.Obsidian
Place it in one of the PATHs that your desktop environment monitors (one should be ~/.local/share/applications/).

Ravine4701 · August 17, 2026, 11:57pm

I had the same issue, but I’m running KDE/Wayland on CachyOS (Arch based). I read your note on installing the AppImage, so I uninstalled the AUR version which was 1.12, and installed the AppImage from your website and the icon issue was fixed. There is an issue that the AUR repository is still showing 1.12. I’m new to Linux, so I’m not sure how to report this. My ask to you is: Can you tell me how I can alert them to this issue, or would it be more effective for the Obsidian devs to reach out?

rbcn2000 · August 24, 2026, 1:02pm

Thanks for taking a look at this, and for the pointer on the Wayland side — that’s a fair distinction I hadn’t spelled out, and I don’t have any reason to doubt it for a Wayland session.

To be precise about what I tested: my environment is plain X11/Xfce, not Wayland:

XDG_SESSION_TYPE=x11
WAYLAND_DISPLAY=
DISPLAY=:0.0

I went ahead and reproduced your suggested .desktop configuration exactly, with open-obsidian (my own launcher wrapper) and GearLever both out of the picture entirely — official Obsidian AppImage 1.13.7, launched directly via gtk-launch from a md.obsidian.Obsidian.desktop file, using an isolated --user-data-dir so it wouldn’t touch my regular vault/session.

The window’s actual WM_CLASS came back as:

WM_CLASS(STRING) = "md.obsidian", "md.Obsidian"

Test B — your suggested config as-is:

StartupWMClass=md.obsidian.Obsidian
_NET_WM_ICON: absent
libwnck is_fallback: True
Xfce taskbar: generic icon

Still generic.

Test C — StartupWMClass adjusted to match the actual WM_CLASS:

StartupWMClass=md.Obsidian
_NET_WM_ICON: absent
libwnck is_fallback: True
Xfce taskbar: generic icon

No difference from Test B — changing StartupWMClass didn’t move the needle either way.

Test D — same running window as Test C, .desktop left untouched, only injecting _NET_WM_ICON:

_NET_WM_ICON: present
libwnck is_fallback: False
Xfce taskbar: correct Obsidian icon

This is the one that actually flipped it — same window, same .desktop, the only variable was the presence of _NET_WM_ICON, and both libwnck’s fallback flag and the actual taskbar icon changed together immediately.

So I don’t think this contradicts what you said about Wayland. But at least on the X11/Xfce path (which goes through libwnck), the .desktop/StartupWMClass configuration you suggested didn’t change the outcome in either direction.

The issue also reproduces the same way with my wrapper and GearLever completely removed from the test path, so they don’t appear to be part of the trigger condition here.

The one thing that correlated with the fix on this path was the window itself carrying an _NET_WM_ICON, which Obsidian doesn’t currently set in this X11 environment.

Happy to share the exact .desktop file I used, how I checked the libwnck fallback flag, and the minimal script I used to inject _NET_WM_ICON for reproduction, if that’s useful on your end.

Kzer-Za · August 29, 2026, 6:07am

I can confirm this issue on X11/XFCE, and I did some additional testing that may help narrow down the regression.

First, regarding the suggestion above to set StartupWMClass: my installed Obsidian desktop entry already has exactly the suggested value:

Icon=obsidian
StartupWMClass=md.obsidian.Obsidian

So, at least on XFCE/X11, having StartupWMClass=md.obsidian.Obsidian in the desktop entry does not by itself fix the missing window/taskbar icon.

I’m using XFCE with xfce4-panel. With Obsidian 1.13.7, the Obsidian icon is missing both from the window title bar and from the Window Buttons plugin on the XFCE panel.

With Obsidian 1.13.7:

$ xprop WM_CLASS _NET_WM_ICON WM_HINTS

WM_CLASS(STRING) = "md.obsidian.obsidian", "md.obsidian.Obsidian"
_NET_WM_ICON:  not found.
WM_HINTS:  not found.

libwnck also reports that it is using a fallback icon:

Class group: md.obsidian.Obsidian
Class instance: md.obsidian.obsidian
Icon fallback: True
Icon size: 32 x 32

However, I downgraded Obsidian to 1.12.7, and the interesting part is that _NET_WM_ICON is absent there as well:

WM_CLASS(STRING) = "obsidian", "obsidian"
_NET_WM_ICON:  not found.
WM_HINTS:  not found.

Despite this, with 1.12.7 an Obsidian icon does appear both in the title bar and on the XFCE panel (although its sizing does not look quite right).

So the absence of _NET_WM_ICON by itself is not new in 1.13.x and does not seem sufficient to explain the regression. One relevant change is that WM_CLASS changed from:

"obsidian", "obsidian"

in 1.12.7 to:

"md.obsidian.obsidian", "md.obsidian.Obsidian"

in 1.13.7.

It looks as though XFCE/libwnck was able to find a suitable fallback icon with the old WM_CLASS, but can no longer do so with the new one. This is only an inference from the observed behavior, however.

I also tested Settings → Appearance → Custom app icon in Obsidian 1.13.7. After setting it to a 48×48 Obsidian PNG and restarting Obsidian, both the title-bar and XFCE-panel icons appear and are sized correctly. Obsidian then does provide _NET_WM_ICON:

WM_CLASS(STRING) = "md.obsidian.obsidian", "md.obsidian.Obsidian"
_NET_WM_ICON(CARDINAL) = Icon (48 x 48)
WM_HINTS:  not found.

So setting a custom app icon is an effective workaround for me.

For completeness, I also verified that GTK can successfully resolve obsidian from the hicolor icon theme. Therefore the problem does not appear to be caused simply by a missing icon file, and the desktop entry already contains the expected StartupWMClass.

highland_dave · September 3, 2026, 3:19pm

Adding a data point, because I hit this same symptom through a completely
different mechanism — and I think the fix proposed above wouldn’t address it.

Environment

Obsidian 1.13.7, snap package (rev 67, classic confinement, publisher obsidianmd)
Ubuntu 24.04.4, GNOME Shell 46.0, Wayland session
Symptom: generic cog in the dock, but the correct icon in the app grid.
Hovering the dock entry showed the literal string md.obsidian.Obsidian
rather than “Obsidian”, and the app couldn’t be pinned.

That hover label is the tell: GNOME only shows a raw app-id like that when it
has failed to match the window to any installed .desktop entry and fallen
back to a synthetic “window-backed” app.

Why this isn’t the _NET_WM_ICON case

The window is a native Wayland client (it doesn’t appear in
xprop -root _NET_CLIENT_LIST), so _NET_WM_ICON doesn’t exist for it at all.
GNOME doesn’t consult it regardless — it matches the window to a .desktop
entry and draws that entry’s Icon=. So this is a matching failure, not a
missing-pixmap failure.

What actually breaks, for the snap

snapd exports each meta/gui/*.desktop as <snap-name>_<basename>.desktop.
Obsidian ships meta/gui/md.obsidian.Obsidian.desktop, so it lands as:

/var/lib/snapd/desktop/applications/obsidian_md.obsidian.Obsidian.desktop

Meanwhile the running process carries the AppArmor label
snap.obsidian.obsidian (classic confinement still sets a label — mine is in
complain mode), and GNOME/Mutter derive a sandbox identity from that label.
Comparing against a snap whose icon works correctly on the same machine:

app	AppArmor label	exported desktop file	matches
Slack	`snap.slack.slack`	`slack_slack.desktop`	yes
Obsidian	`snap.obsidian.obsidian`	`obsidian_md.obsidian.Obsidian.desktop`	no

Each exported file also declares its own X-SnapAppName. Checking all 14 snap
desktop files on my system, the filename matches <X-SnapInstanceName>_<X-SnapAppName>
in every case except one — Obsidian’s, which declares X-SnapAppName=obsidian
but is exported as obsidian_md.obsidian.Obsidian.desktop.

Why StartupWMClass doesn’t fix it here

Worth flagging, since that’s the usual advice: the snap’s exported entry
already contains StartupWMClass=md.obsidian.Obsidian, and that value is
correct — WAYLAND_DEBUG=1 confirms the window sets
xdg_toplevel.set_app_id("md.obsidian.Obsidian"). It still doesn’t match,
because once a window has a sandbox identity GNOME won’t fall back to
StartupWMClass matching (sensibly — it stops a sandboxed app claiming another
app’s WM class). So for snap users, adding a .desktop file with
StartupWMClass has no effect. The filename is what matters.

Workaround for snap users

Create ~/.local/share/applications/obsidian_obsidian.desktop:

[Desktop Entry]
Type=Application
Name=Obsidian
Exec=/snap/bin/obsidian %U
Icon=/snap/obsidian/current/meta/gui/obsidian.png
Terminal=false
StartupWMClass=md.obsidian.Obsidian
MimeType=x-scheme-handler/obsidian;
Categories=Office;

Then fully quit and relaunch Obsidian (GNOME caches the window→app association
per window). Correct icon, and it pins normally. To avoid a duplicate entry in
the app grid, add a second file obsidian_md.obsidian.Obsidian.desktop in the
same directory with identical contents plus NoDisplay=true — your local copy
shadows the snap’s export. Use NoDisplay, not Hidden, or obsidian://
links stop working.

One caveat on my confidence: I established the filename rule empirically rather
than from GNOME’s source — adding that exact filename fixed matching, while the
already-correct StartupWMClass on the snap’s own entry never did.

Suggested packaging fix

Rename the snap’s meta/gui/md.obsidian.Obsidian.desktop to
meta/gui/obsidian.desktop (matching the snap’s app name). snapd would then
export obsidian_obsidian.desktop, and matching works with no user action.

Possibly the same root cause as the X11 regression

Kzer-Za’s bisect above — WM_CLASS changing from obsidian to
md.obsidian.Obsidian between 1.12.7 and 1.13.7 — lines up with this. If the
meta/gui/ desktop file was renamed to follow the new app id in the same
change, that single rename would explain both the X11 icon-name regression and
this snap export mismatch. Might be worth checking whether the 1.12.x snap
shipped meta/gui/obsidian.desktop.

Finally: setting icon on the BrowserWindow so _NET_WM_ICON gets populated
would fix the Xfce/libwnck case, but it wouldn’t change anything for snap on
GNOME/Wayland, since no window property is consulted there. These look like two
separate fixes for one symptom.

WhiteNoise · September 5, 2026, 6:54pm

To wrap up,

For the AppImage, the solution is my first post.
For the Snap, the issue is more complex than it seems, I have investigated extensively in the past two weeks and opened a few upstream reports (continue here).

The problem is not X-SnapAppName=obsidian, because changing it to X-SnapAppName=md.obsidian.Obsidian doesn’t solve the problem. Anyway, please continue in the thread I linked.

For other packages that we make (deb, flatpak), open a separate BR.
For package that we don’t make, sorry we don’t provide support for them.