AppImages cause Loop Device mounting; can this be a cumulative problem?


I’ve come to realise that each time i launch an AppImage, a Loop Device is mounted

This is not the same AI that i’m using, but this user seems to have the same experience… GIMP AppImage (continuous integration) - #13 by Carmelo_DrRaw - GIMP - :

I think this an unavoidable price to pay… as far as i understand it, the appimage is a compressed disk image. Each time it is launched the system needs to uncompress the image and mount it via a loop back device.

My concern is that each time i’ve finished using the pgm & close it, the Loop Device remains mounted. Next time i run the AI, another Loop Device mounts… then another, then another. Sometimes Dolphin exhibits a long list of these in its lhs panel. Here, in the current TW session [ie, between reboots] i’ve only run it twice, & there’s 2 LDs mounted [but other times i’ve seen 4, 5, 6…].

My question is: sooner or later, will this apparently never-ending accumulation of mounted LDs cause TW any kind of problem?

If it’s not clearing the loop device then to me it’s a bug in the image (or the underlying process that starts app image?). You can check the kernel config, AFAIK default is 256.

if you need info on how to unmount and more, I wrote a Wiki that aggregates info from a number of loop device documentation and summarized


I read your article and while I have no doubt it is all very true what you documented, but I am really interested in what the losetup is good for.

I have read the man pages of mount an umount (well, in this case not from top to bottom, but specially what they say about loop devices).

in man mount there is a special section about " THE LOOP DEVICE" where you can see that you can use mount for setting up the loop device (in most cases the defaults look fine to me) and the mounting of course.

Likewise man umount has the --detach-loop option to do what it says after the unmounting.

My question, what is the extra usage of losetup bringing?

I did not read enough of man umount. It says:


The umount command will free the loop device (if any) associated with the mount, in case it finds the option ‘loop=…’ in /etc/mtab, or when the -d option was given. Any pending loop devices can be freed using ‘losetup -d’, see losetup(8).

Thus it seems that you can do perfectly with mount and umount and that losetup is only needed when something goes wrong.

Another option is to simply configure your machine to set up more than 8 loop devices, that’s only a default number.
Of course, if you end up with a large number of loop devices mounted, it will

  • Use more resources
  • Will have to be unmounted eventually, possibly on shutdown which will mean that takes longer.


Thanks Malcolm, tsu2 & Henk

I’m not ignoring anyone here, but need time to digest the info herein & referenced, to understand it & what i should do.

I do not Shutdown my Tower each night, but instead Suspend it, then Resume the next morning. If it was only up to me, i would only reboot weekly, given i do my TW zypper dups weekly. Sadly however, Tower rarely gets to the target 7 days Uptime, but instead maybe every 3 or 4 [maybe 5] days something goes wrong that either causes it to freeze & reboot itself, or freeze & need me to REISUB etc. I realise there’s vast numbers of possible causes [some of which have been canvassed in previous threads], but now reading your comment here, i’d like to ask this… could these accumulating Loop Devices which “Use more resources”, lead to some critical point in “resources” demand that causes the misbehaviour i described?

I doubt this when you are up to a max of 8. I think the warning there is directly connected to when you do increase the max as he suggests as a possible solution (bypass).

That’s good news then - thanks Henk.

There are actually a variety of ways that loop devices are mounted…

  • Can be invoked in Grub to make a block device or file system available during bootstrap
  • Whenever you use a virtual disk file in any virtualization, it’s mounted as a loop d4vice

As you reference the mount command can be used, but also as you note it’s not as reliable or full an implementation as using losetup.

For myself,
I use losetup to remind me what kind of device is mounted… Unless there is a special need to use the mount command like in fstab, I prefer to keep track of my loop devices separately from others.


As usual, it depends on what your needs are. Thanks for the clarification.

Thank you all very much for your assistance. I’m pleased to say that i have now worked around this problem, by no longer needing to use this KeePassXC AppImage, as per

Today i was teaching myself about the grep command in openSUSE [the syntax i thought i knew back in Mint & Maui is slightly different in oS, so i wanted to get myself up to speed]. I also practiced concatenating grep with some other commands… hey wow, this is really powerful handy stuff :wink: This lead to an entirely accidental discovery. A few weeks ago when the subject of this thread was super-active for me, not only was i experimenting with AppImages, but also Snap packages. My accidental discovery today is this:

gooeygirl@linux-Tower:/> **df -h | grep 100%
**/dev/loop2                                                           77M   77M     0 100% /snap/keepassxc/26
/dev/loop1                                                           84M   84M     0 100% /snap/core/3017
/dev/loop0                                                           77M   77M     0 100% /snap/keepassxc/25
/dev/loop3                                                           77M   77M     0 100% /snap/keepassxc/24
/dev/loop4                                                           82M   82M     0 100% /snap/core/2898
/dev/loop5                                                           84M   84M     0 100% /snap/core/3247

I have not used any Snap packages for a couple of weeks, & now that i have solved the main objective of this thread, i do not envisage in the near future having to start using them again. I think there’s been a couple of reboots since i last used any of those, yet all those Loop Devices are still mounted how? why?]. So my question is… given the above discovery [which quite shocked me], is it safe for me to now simply run these commands?:

umount /dev/loop0
umount /dev/loop1
umount /dev/loop2
umount /dev/loop3
umount /dev/loop4
umount /dev/loop5


No need now for anyone to waste their time on my previous query; i’ve sussed it out myself.

I practiced this first in my Test TW VM, then did it in Tower’s real TW.

Manually unmounting all those LDs didn’t cause anything to explode, but after rebooting i discovered that most of them had remounted… not happy with that. After more experimentation i discovered that these automatic mounts each boot were caused by the snapd daemon itself, irrespective if i’d actually launched any specific Snap-package pgm [eg, the [i]KeePassXC Snap] itself. I felt this was rather bad manners of Snap, & given i’ve now solved my original objective & thus am back to using the repo KeePassXC version with the full functionality, the Snap package is redundant. Therefore i chose to do these, which succeeded, coz following another reboot, no more Loop Devices have mounted.

gooeygirl@linux-Tower:~> **df -ah | grep loop
**/dev/loop2                                                           77M   77M     0 100% /snap/keepassxc/26
/dev/loop1                                                           84M   84M     0 100% /snap/core/3017
/dev/loop0                                                           77M   77M     0 100% /snap/keepassxc/25
/dev/loop3                                                           77M   77M     0 100% /snap/keepassxc/24
/dev/loop4                                                           82M   82M     0 100% /snap/core/2898
/dev/loop5                                                           84M   84M     0 100% /snap/core/3247

gooeygirl@linux-Tower:~> **sudo umount /dev/loop***
[sudo] password for root: 
umount: /dev/loop6: not mounted.
umount: /dev/loop7: not mounted.
umount: /dev/loop-control: not mounted.

gooeygirl@linux-Tower:~> **df -ah | grep loop**

gooeygirl@linux-Tower:~> **sudo systemctl disable snapd**
Removed /etc/systemd/system/

gooeygirl@linux-Tower:~> **sudo zypper rm snapd**
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following package is going to be REMOVED:

1 package to remove.
After the operation, 30.4 MiB will be freed.
Continue? [y/n/...? shows all options] (y): 
(1/1) Removing snapd-2.27.6-1.5.x86_64 ..................................................................................................................................[done]
Additional rpm output:
Stopping snap-core-2898.mount
Removing snap core
Removing snap-core-2898.mount
Stopping snap-core-3017.mount
Removing snap core
Removing snap-core-3017.mount
Stopping snap-core-3247.mount
Removing snap core
Removing snap-core-3247.mount
Stopping snap-keepassxc-24.mount
Removing snap keepassxc
Removing snap-keepassxc-24.mount
Stopping snap-keepassxc-25.mount
Removing snap keepassxc
Removing snap-keepassxc-25.mount
Stopping snap-keepassxc-26.mount
Removing snap keepassxc
Removing snap-keepassxc-26.mount
Discarding preserved snap namespaces
Removing downloaded snaps
Final directory cleanup
Removing leftover snap shared state data
warning: file /snap/bin: remove failed: No such file or directory

gooeygirl@linux-Tower:~> **df -ah | grep loop**


So that was another learning experience for me… Snap will mount LDs by itself every boot, thus consuming some level of system resources i presume, even if i never subsequently launch any actual Snap-package pgm. I do not like that misbehaviour… hence no more Snap for me.