ENOSPC: System limit for number of file watchers reached happens if you have too many files open on a system. By default this limit is set very low (65535) but it’s trivial to increase it: Obsidian starts with blank screen
After downloading the AppImage, and make it executable chmod +x Obsidian-0.8.14.AppImage, you should place it somewhere in your PATH as described here, e.g. in ~/bin/.
To add a desktop entry, you can create an obsidian.desktop file and place it in either /usr/share/applications/ or /usr/local/share/applications/ for applications installed system-wide, or ~/.local/share/applications/. The contents should look something like this:
AppImages are—in my opinion—the better alternatives to FlatPak or Snap. Thanks to the Obsidian team for providing one! Since AppImages run on such a variety of Linux systems, they don’t easily “self-integrate” into the miscellaneous desktop environments out there.
The easiest way is to use AppImageLauncher, especially if you use more than just one or two AppImages.
But it can be done manually, too. The basic steps here are:
Get the AppImage and make it executable.
Put it in a sensible location (I use ~/AppImages but some prefer /opt).
Get an application icon and store it where your DE can use it.
Make a “starter” (.desktop) file and put it in a location appropriate for your DE. A normal text editor can be used for this.
Here is an example for how I did it on my Linux Mint 20.1:
Download the Obsidian AppImage.
I moved it to ~/AppImages/Obsidian-0.10.11.AppImage.
Make it executable: chmod +x ~/AppImages/Obsidian-0.10.11.AppImage.
For those of you out there who aren’t using Flatpak (I installed Obsidian from AUR), you can enable Wayland by calling obsidian with --enable-features=UseOzonePlatform --ozone-platform=wayland options.
I tried calling Obsidian with environment variable OBSIDIAN_USE_WAYLAND=1, but it didn’t work for some reason.
@gnull Are you calling OBSIDIAN_USE_WAYLAND=1 from within the Obsidian flatpak, or from the AUR build? If the former, then you need to make sure that you’re running in a Wayland session:
$ echo $XDG_SESSION_TYPE
So far this has been extensively tested in Gnome Shell. Other Wayland compositors like KDE and Sway will need feedback.
It’s also worth noting that OBSIDIAN_USE_WAYLAND is a custom environment variable for easily testing Wayland support, so it’d make sense if it didn’t do anything in other builds. This variable is declared here:
I think X11 will continue to be a fallback for applications that cannot function completely under Wayland, and for all intents and purposes that’s fine. There’s a lot of new development happening in the Linux desktop ecosystem right now, and with it comes an awkward adjustment period where new APIs are introduced and applications are eventually updated to use them to gain back functionality that was previously provided under X11.
I think in the case of Obsidian it seems to work readily under Wayland, as it’s not primarily using parts of the stack that’ve historically been pain points in Wayland (screen sharing, hot keys, etc). For most users who’re running Wayland compositors, there probably won’t be a noticeable difference.
I am using the extracted AppImage, but the Obsidian URI didn’t work.
The issue was that the AppRun file didn’t get the $APPDIR supplied, so it didn’t get the correct path to execute the binary.
Below is part of the AppRun with the change I made.
# Supply the path to where the extracted AppImage is
# below is just an example
if [ -z "$APPDIR" ] ; then
# Find the AppDir. It is the directory that contains AppRun.
# This assumes that this script resides inside the AppDir or a subdirectory.
# If this script is run inside an AppImage, then the AppImage runtime likely has already set $APPDIR