AppImage fails to launch on Arch Linux with "fuse: memory allocation failed" v. 3.14.7

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I have been running Cursor exclusively through the official Linux AppImage on Arch Linux for a long time and never had this issue before. It only started with the current build, 3.14.7 x64. The AppImage fails to launch with a FUSE mount error, but I confirmed the downloaded file itself is not corrupted and the squashfs payload inside it is valid. This looks like a version incompatibility between the AppImage’s bundled runtime and current fuse3/glibc on rolling release distros like Arch.

Steps to Reproduce

  1. Download Cursor-3.14.7-x86_64.AppImage from the official download URL.
  2. chmod +x Cursor-3.14.7-x86_64.AppImage
  3. Run it directly: ./Cursor-3.14.7-x86_64.AppImage
  4. Observe the FUSE error below instead of the app opening.
  5. As an alternative, run ./Cursor-3.14.7-x86_64.AppImage --appimage-extract-and-run, which fails with a different error (also below).

Expected Behavior

The AppImage mounts and Cursor opens normally, as it always did with previous versions.

Operating System

Linux

Version Information

  • OS: Arch Linux, kernel 7.1.5-arch1-2
  • fuse3: 3.18.2-1
  • fuse2: 2.9.9-5
  • squashfuse (system package): 0.6.2
  • Cursor: 3.14.7 x64, AppImage

Additional Information

Direct run:
fuse: memory allocation failed
squashfuse 0.5.2 (c) 2012 Dave Vasilevsky
Usage: squashfuse [options] ARCHIVE MOUNTPOINT

–appimage-extract-and-run:
This doesn’t look like a squashfs image.
Failed to open squashfs image
Failed to extract AppImage.

Investigation / why I don’t think this is a corrupted download

  • Downloaded the file twice, both times got the identical sha256: fa7bed85bd11eedbc01fdb7571de01a88adc8ead7a4b2d95c9c2d6a2f8c1db08.
  • Computed the squashfs payload offset from the ELF section headers (e_shoff + e_shnum * e_shentsize = 942712 + 30*64 = 944632) and confirmed a valid squashfs superblock (magic hsqs, compression id 6/zstd, 128k block size) sits exactly there.
  • Mounted that offset manually with the system’s own squashfuse (version 0.6.2, distro package, newer than the bundled 0.5.2) and the payload is intact: AppRun, icons, desktop file and the cursor binary are all present and readable. Launching AppRun from that manual mount starts Cursor with no issue.
  • Confirmed it’s not a general FUSE problem on my system: a different AppImage in the same folder mounts and runs fine with its own bundled runtime.

Conclusion: the squashfs payload is valid, the download is not corrupted, and my system’s FUSE stack works. The bundled runtime in this AppImage (reporting itself as squashfuse 0.5.2) appears to crash on newer glibc/fuse3 (I have fuse3 3.18.2) instead of falling back gracefully, both in the direct mount path and in the internal extract-and-run path.

Does this stop you from using Cursor

Yes - Cursor is unusable

5

Hey, thanks for such a detailed report, it really helps.

I checked on our side: the published Cursor-3.14.7-x86_64.AppImage matches your sha256 (fa7bed85...) and on a clean machine it mounts and extracts fine, and its runtime is byte identical to the 3.12.x builds that worked for you. So the file itself looks good.

The most interesting part in your report is that even --appimage-extract-and-run failed. That path does not use FUSE at all, it just reads the squashfs at a calculated offset. Getting “This doesn’t look like a squashfs image” on known valid bytes usually means you were not running the AppImage’s own runtime. Instead something intercepted it via binfmt_misc, most often AppImageLauncher. Its older squashfs code does not support zstd (Cursor AppImages are zstd), while older xz compressed AppImages work fine. That also explains why another AppImage in the same folder runs.

Could you please check:

pacman -Q appimagelauncher
ls /proc/sys/fs/binfmt_misc/

Look for entries like appimage-type2 or AppImageLauncher. If it is installed, uninstall it and reboot, then try running the AppImage again. Note that AppImageLauncher intercepts even a direct ./Cursor.AppImage run based on magic bytes, so renaming will not help.

If you want GUI integration for AppImages, you have two options that support zstd: update AppImageLauncher to the latest alpha build (3.0.0-alpha-4 or newer), or switch to Gear Lever as a modern replacement.

Your manual mount using the system squashfuse is a valid workaround while you troubleshoot.

Let me know what those commands show and whether uninstalling helped. If not, we will dig further.

7

Thank you, yes it helped.
pacman -Q appimagelauncher

$ appimagelauncher 2.2.0-9

and ls /proc/sys/fs/binfmt_misc/

$ appimage-type1 appimage-type2 DOSWin register status

image
image1241×635 85.8 KB