Hey all, recently I was doing some work on the machine where I host my plex and audiobookshelf servers and I noticed that there were 3 new devices listed in the disk manager.
All 3 of the new devices have a description along the lines of “78MB Loop Device” and lists a backing file at location /var/lib/snapd/snaps/snapd_22291.snap (not exactly but they’re all similar to this). They show as unmounted and I’m not really sure what this is.
Additionally when I try to use libation to pull my latest audible books down it says it can’t read my local file location folder.
I recently saw the post about the plex vulnerability (which is part of why i was doing work on it, to make sure that my auto update was working) when I noticed this and it got me worried.
Are these new devices that showed up indicative that a malicious user has accessed my system through the internet and has setup a crypto miner to run in the background on my server or is it more likely that a disk is failing and this is the first sign?
Also before anyone feels the need to say it, I know that plex is not ideal and jellyfin is better, but I have remote users that I cannot talk through troubleshooting to get jellyfin when I can tell them to just install plex on their end.
Any help would be greatly appreciated
They don’t go away on their own, every installed snap is mounted as its own loop device and snapd keeps an older revision or two so it can roll back, so the number moves around after updates.
snap list --allshows which snaps they are, if one says disabled that’s the old revision and you can remove it withsudo snap remove <name> --revision=<rev>. about libation, if it’s installed as a snap itself that could be the actual problem, snaps are confined and can’t read folders outside your home or on other drives unless you connect the removable-media interface, so I’d check that before worrying about the loop devices.Awesome! That was going to be the next thing I looked up was how to do the snap list. It shouldn’t be impacting my libation as that is running in a docker instance managed by portainer. Though now that I think back I had initially installed libation using snap, but couldn’t get it to work, so perhaps I have both instances running and am trying to use the snap one on accident when I need to be opening the docker instance.
Loop devices are just files mapped as block devices. Snaps cordon off an area on disk for install and config, you should probably see more than one per app if you updated, that’s how snaps can be reverted to previous versions. You can set how many versions snaps keep per app.
That makes sense, are they intended to persist indefinitely, only while the subject application is running, or do they go away after a period of time? Thanks for your help!
I have limited exposure to snaps, but from my experience, the oldest eventually gets overwritten by newer ones.
If the backing files are referencing “snapd”, then it seems plausible that these are the sandbox filesystems for software packaged using the Snap environment.
Okay, I have used snap to install things before but it never generated these faux disks that I can’t seem to delete. Would you guess that it is a temporary issue and a restart should resolve? (haven’t restarted yet because I have been using the audiobookshelf and plex and haven’t scheduled a maintenance window yet)
What makes you think it’s an issue? What problem is it causing? You can probably identify which snap they belong to.
I don’t know for certain that these unexpected devices in my disk manager are causing the issue, but I noticed them at the same time as the issue with libation being unable to access the directory it normally uses and so I may be conflating 2 unrelated issues
I believe you are conflating two unrelated things. Snap regularly creates those devices, it’s normal, required for snaps to work, and nothing to worry about at all.
Oh okay, so do they go away on their own or do they persist potentially indefinitely? I have used snap in the past but had never noticed these until now. I guess I was just paranoid after the plex vulnerability news haha. Thanks.
