Gnome-disk-image-mounter

In Debian 11 ( either with Gnome or Xfce) there is a program

#which gnome-disk-image-mounter
/usr/bin/gnome-disk-image-mounter

and it has a man page

#man gnome-disk-image-mounter

GNOME-DISK-IMAGE-MOU(1)       gnome-disk-utility       GNOME-DISK-IMAGE-MOU(1)

NAME
       gnome-disk-image-mounter - Attach and mount disk images

SYNOPSIS
       gnome-disk-image-mounter [--writable] [URI...]

DESCRIPTION
       gnome-disk-image-mounter can be used to set up disk images. Both
       regular files and GVfs URIs (such as smb://filer/media/file.iso) can be
       used in the URI parameter. If no URIs are given and a window server is
       running, a graphical file chooser will be presented.
 ......................

but when I execute it , it fails

nevj@trinity:~$ gnome-disk-image-mounter

brings up a window to select a disk image file


and when I click on mount it gives an error

I assume what it is meant to do is perform a loop mount.
Has anyone been able to make it work?

It is a bit of a mystery item. It does not exist as a package of that name. It must be part of some other gnome package?

1 Like

Hi Neville. :wave:

Well, that´s just great. I looked it up on my system (Lubuntu) and found out I´ve got it installed (by default it seems) as well. I never knew it. :blush:
So thanks for bringing it to my attention.

I tried it and it seems I can´t help you.
Actually I didn´t encounter any problems.

I tried 2 ways of running the programme.

  • the way you described it. I also got that window letting me choose which ISO to use. After clicking on it pcmafm-qt opened up and I could access all files of the ISO. (a fatdog ISO BTW)
  • I could achieve the same with the help of thunar. Selecting an ISO the right-click menu would offer me to open the file with disk-image-mounter. The result was the same.

In both cases unmounting it was easy with thunar.

Have you tried the procedure with thunar as well?

Many greetings from Rosika :slightly_smiling_face:

1 Like

Well at least I know now I was not attempting something stupid. It is supposed to be able to mount .iso files.

Will try Thunar, as you suggest.
I think , now I have seen your result, there must be something missing on both my Debian systems, one witth Xfce, one with Gnome.
pcmafm-qt ?? That is Qt? Gnome and Xfce are not Qt

Thanks Rosika, I should be able to sort it now
Regards
Neville

1 Like

Hi Neville, :wave:

Yes, I think so as well.

Yes, I should´ve mentioned that after Lubuntu switched to the LXQt DE pcmafm (still used with LXDE) switched to pcmanfm-qt as the default file-manager.
And it seems it´s the default file-manager where the contents of the ISO are displayed.

I guess if you have another file-manager set as default it´ll be this one then…

Many greetings.
Rosika :slightly_smiling_face:

1 Like

OK, pcmanfm is the default filemanager. In Gnome it is Nautilus, and in Xfce it is Thunar. Should not make any difference.
Mine did not get that far. The error message says that the mount attempt failed.

I will try and do a loop mount by hand

Thanks
Neville

1 Like

Hi Neville, :wave:

Not sure if it helps but perhaps take a look at:

Many greetings from Rosika :slightly_smiling_face:

1 Like

Hi, :wave:

looking a bit further regarding this interesting topic I found on

that gnome-disk-image-mounter can also handle IMG files.
All this seems great but here a proxmox staff member warns:

Just a general warning:
you should NEVER mount an unknown and possibly bad filesystem on a machine that contains important info/has access to an important network
a filesystem prepared by an attacker can abuse kernel fs bugs (which are not seen as security issues by the kernel)

i’d suggest to only mount unknown filesystems in a vm

Hmm, that makes me wonder: :thinking:

If I make use of gnome-disk-image-mounter and see an ISO´s or IMG´s contents in any file-manager … what could possibly go wrong :question:
Why might that be hazardous?

Many greetings
Rosika :slightly_smiling_face:

2 Likes

Hi Rosika,
I cant see that it is any more hazardous than writing it to a CD or a USB drive, and mounting it that way.
What I think matters is that an .iso file can contain a live filesystem, ie one that you can boot, and it is when you boot something that can be hazardous if it has been tampered with.
In general, it is only files that you execute that can be hazardous.

When you download a .iso file, you should always do the md5 checksum. That guarentees that your copy is the same as the one the original author deposited online.
And we should use trusted sites to download from.

Regards
Neville

1 Like

Hi @Rosika,
My attempt to do a loop mount by hand failed

nevj@mary:~/Downloads$ su
Password: 
root@mary:/home/nevj/Downloads# mount -o loop GhostBSD-22.06.15.iso /mnt
mount: /mnt: mount failed: Operation not permitted.
root@mary:/home/nevj/Downloads# 

So I think the reason gnome-disk-image-mounter fails is that loop mounts are not permitted in my Debian 11.

That bears further investigation

Regards
Neville

1 Like

It works in Void linux

# mount -o loop void-live-x86_64-20210930.iso /mnt
mount: /mnt: WARNING: source write-protected, mounted read-only.
# ls /mnt
LiveOS	boot
# umount /mnt
#

The difference between Void and Debian is that Void has loop devices in /dev

[nevj@trinity ~]$ ls /dev/lo*
/dev/loop-control  /dev/loop1  /dev/loop3  /dev/loop5  /dev/loop7
/dev/loop0         /dev/loop2  /dev/loop4  /dev/loop6
[nevj@trinity ~]$ 

while Debian has no loop devices in /dev

So I apparently need to learn how to make loop devices in Debian? … something to do with losetup(8) maybe?

1 Like

Hii Neville, :wave:

thanks so much for your detailed explanation. :heart:

I see.
O.K. then, that confirms what I´ve been thinking all along - that files which I exectue could be dangerous (if they were so designed).
So just mounting an ISO and merely looking into its contents (which was what i did) should have been o.k. :wink:
Perhaps I´m a bit over-cautious or even paranoid, but that way I at least keep learning something new. Thanks again.

O.K. That´s what I always do. Thanks once more.

Oh, sorry to hear that. :slightly_frowning_face:

In order to look that one up in my Debian 10 VM I just started Debian Buster and got the following result:

rosika2@debian ~> ll /dev/lo*
lrwxrwxrwx 1 root root      28 Jul  4 14:11 /dev/log -> /run/systemd/journal/dev-log=
brw-rw---- 1 root disk  7,   0 Jul  4 14:11 /dev/loop0
brw-rw---- 1 root disk  7,   1 Jul  4 14:11 /dev/loop1
brw-rw---- 1 root disk  7,   2 Jul  4 14:11 /dev/loop2
brw-rw---- 1 root disk  7,   3 Jul  4 14:11 /dev/loop3
brw-rw---- 1 root disk  7,   4 Jul  4 14:13 /dev/loop4
brw-rw---- 1 root disk  7,   5 Jul  4 14:11 /dev/loop5
brw-rw---- 1 root disk  7,   6 Jul  4 14:11 /dev/loop6
brw-rw---- 1 root disk  7,   7 Jul  4 14:11 /dev/loop7
crw-rw---- 1 root disk 10, 237 Jul  4 14:11 /dev/loop-control

I guess it should work then here. :thinking:

O.K., I tried it and indeed it works:

rosika2@debian ~> mount -o loop /home/rosika2/Dokumente/kgw_prov/Fatdog64-812.iso /home/rosika2/mountpoint
mount: only root can use "--options" option  # I forgot I had to use sudo
rosika2@debian ~> sudo mount -o loop /home/rosika2/Dokumente/kgw_prov/Fatdog64-812.iso /home/rosika2/mountpoint
[sudo] Passwort für rosika2: 
mount: /home/rosika2/mountpoint: WARNING: device write-protected, mounted read-only.
rosika2@debian ~> echo $status
0

I looked into thunar and all the contents if the ISO file were there.

So at least I can confirm your method works in Debian10 Buster. Why there should be any difference to Debian11 I cannot tell. :thinking:

Many greetings from Rosika :slightly_smiling_face:

1 Like

Hi Rosika,
Thats interesting thank you. My Debian was originally Debian 10, but I did a cross-release upgrade to Debian 11. Maybe the loop device files were lost during the cross-release upgrade? Or maybe Debian changed its policy.
This might be my first major problem arising from a cross-release upgrade.

To find out I need to do a fresh install of Debian 11 . I can do that in Virtualbox. Actually I just did a fresh new install of Devuan 4 in Vbox. That should be same as Debian 11. Will have a look at its dev files.

This is turning into a you beaut detective story

Regards
Neville

1 Like

Hi Neville, :wave:

You´re very welcome. :heart:

Ah, I see. The term “cross-release upgrade” was new to me. I guess that shoud be an equivalent to “inline-upgrade”…, so basically the method of upgrading from one version (buster) to the next one (bullseye) without having to do a fresh-/clean install.

One never stops learning. :smile:

Uh, that might me unfortunate then.

I was taking a look at the package list bullseye vs. buster:

and was looking for occurences of the keyword “loop”.

In (1) there are 41 matches whereas in (2) there are 53 matches. I haven´t looked at all of them but at least there seems to have been some change :question: :thinking:
I don´t know however if those findings could be relevant at all…

Yes, it seems so. I´m very interested to see what you come up with.

Many greetings
Rosika :slightly_smiling_face:

1 Like

I think, one major problem about this issue is the UNIX-styled terminology here. Instead of naming something reasonable, it has an awfully low-level you-must-know-everything-about-unix styled name.

Essentially, loop devices are just files on your Linux installation, that are mounted like disks, which essentially means the files just need a file system and then you can mount them. This is usually the case for disk images and discs.

This is the best short and easy to understand explanation I could find. It’s no magic, but the name is just very confusing.

My point is, that there aren’t loop devices “missing”, because they are not essential per sé. If you need a specific image to be accessed, they might be necessary in certain scenarios, but technically, they don’t have to be there by default.

Therefore, if there are no loop devices on Debian, there is nothing wrong with that fact. It just means, no loop devices were needed.

I personally had almost always good experiences with making cross-release upgrades on Debian. It pretty much always went smooth, without an issue. In fact, it went so smooth, I couldn’t believe it so I was usually testing a couple of functionalities if they were still working and they did.
The problems arise when you have very specific locked in third party software, which depend on very specific library versions and the new Debian version happens to upgrade them. Then you get actual issues.

Needless to say, always create a backup beforehand. Ideally, before every single apt upgrade

This shouldn’t work, because /mnt is the general directory for mounting devices of any kind. If you mount to that root directory, you will block off any other potential devices from being mounted. Therefore, it’s best to just mount into a sub-directory, /mnt/ghostbsd.

mkdir /mnt/ghostbsd
mount -o loop GhostBSD-22.06.15.iso /mnt/ghostbsd

To be clear, it’s not impossible to mount on /mnt and it was maybe less uncommon 20 years ago, but since it’s just a bad choice to mount it like that, distribution conventions went away from it. However, as it is the case for Debian, it might’ve also just be the case that something was already mounted in /mnt which would be another explanation for why an additional mount was prohibited on that directory. This is another reason, why one should just create a sub-folder and mount the device on that sub-folder.

General rule of thumb:
If you are logged in as the root user and you still get permission denied on certain operations, then you can be quite sure that your operation simply does not make any sense, from the computer’s point of view.
The only exception I can think of are extended permission attributes. However, issues with this are very rare, because it’s so rarely used.

2 Likes

Hi @Akito, :wave:

That´s great.
No idea if it´s that smooth with Lubuntu as well. I never tried that method before, always did a fresh/clean install.
Perhaps I´ll give it a try next time (next April). :blush:

Thanks for your report on the topic.

Many greetings
Rosika :slightly_smiling_face:

2 Likes

Yes. I think ‘cross-release-upgrade’ might be my own terminology. Sorry for confusing things.

I just used /mnt because I was lazy and knew there was nothing else mounted.

My cross release upgrades of Debian were OK, with one exception. It lost some hand installed scanner drivers. This may not be an upgrade issue, it may be a change of policy. Iam going to check the script files of my upgrades.

Thanks for the reference. I need to know more.
We have this basic fact

  • distros with loop devices present allow loop mounts
  • distros without loop devices present do not allow loop mounts

I need to learn more
Regards
Neville

I have 2 installs of Devuan4 one on HD install which was upgraded from Devuan3… the other a fresh install of Devuan4 in Vbox.
So what loop devices are present in these 2 installs?
They are both the same. When you login ls /dev/lo* shows only loop-control , no devices loop0, loop1,...
If I do a loop mount
mkdir /tmp/nj (to keep @Akito happy)
then
mount V*.iso /mnt/nj
the mount works and I can see the files inside the .iso
and… the devices loop0, loop1, .....loop7 are now present.
So mount automatically makes them.
If I reboot they disappear, and I am back to just loop-control
So Devuan works differently, and there is no upgrade issue.

In Void and Solus, the devices loop0, ... loop7 and 'loop-control` are present when you login, and are persistant. Loop mounts work in Solus and Void.

Back to Debian 11… that is my Debian 11 upgraded from Debian 10 ( which @Rosika has verified has the loop devices and will do loop mounts successfully).
When I login there are no devices loop0,.. loop7 and no loop-control device. Loop mounts do not work.
An attempt to use losetup failed

$ dd if=/dev/zero of=file.img bs=1MiB count=10
# losetup /dev/loop0 file.img
losetup: /dev/loop0: failed to set up loop device: No such file or directory

So, after a bit of reading I decide to see if the loop.ko kernel module is actually present in the current kernel

# lsmod | grep loop
#

Nothing there , so add the loop module to the running kernel

# modprobe -a loop
# lsmod | grep loop
loop                   36864  1
#

So now the loop module is added, look again at /dev

$ ls /dev/lo*
/dev/log    /dev/loop1  /dev/loop3  /dev/loop5  /dev/loop7
/dev/loop0  /dev/loop2  /dev/loop4  /dev/loop6  /dev/loop-control

and all the loop devices are now present
Now try the loop mount again

# mount Downloads/void-live-x86_64-20210930.iso /mnt/nj
mount: /mnt/nj: WARNING: source write-protected, mounted read-only.
# ls /mnt/nj
boot  LiveOS
# umount /mnt/nj

So now the loop mount works, and I can see the content of the .iso file.

So, last step… try gnome-disk-image-mounter again

# gnome-disk-image-mounter 
Error creating proxy: The connection is closed (g-io-error-quark, 18)
Error creating proxy: The connection is closed (g-io-error-quark, 18)
...........
(gnome-disk-image-mounter:2952): dconf-WARNING **: 17:45:57.219: failed to commit changes to dconf: The connection is closed
..........

It brings up the file selection window , I click on the .iso file, and it fails with no message other than those above.
So failed at the last!
Correction: … gnome-disk-image-mounter works if I use it as nevj. It does not work if I use it as root ???

Also the modprobe -a loop is not permanent. I need to put something in /etc/modules to make it add the loop module in at every restart.

Final question:
Why is my Debian 11 install deficient in the loop.ko module?
Three possibilities

  • it was lost in upgrading from Debian 10
  • Debian developers deliberately removed it from Debian 11
  • Debian developers accidentally left it out of Debian 11

We can sort that out if someone has a fresh install of Debian 11 ( ie not one upgraded from Debian 10 like mine).
Would you please have a look at your /dev
ls /dev/lo*
and see if the loop device files are present?

Thanks to @Rosika and @Akito for assistence
Neville

1 Like

Hi Neville, :wave:

thanks a lot for your very detailed account of what you did to get to the bottom of the problem.
I really admire your analytical way of approaching the matter. :+1:

That´s perfectly alright, Neville. I think your terminology is as good as any. I just wanted to make sure I got it right. :blush:

Sounds interesting. May I ask what that exactly means?. Did you write a dedicated script which assists you in your upgrades?

It´s great you found the crucial question the answer to which should provide the key to solving the whole problem. :+1:
I very much hope someone with a fresh Debian11 install can come up with something substantial.

Many greetings from Rosika :slightly_smiling_face:

I used the script command before doing the upgrade… so I have a scriptfile of the whole thing.
Have not looked at it yet. Was rather busy sorting out loop.ko

BTW gnome-disk-image-mounter is part of the gnome-disk-utility package, which also contains gnome-disks. Have you used gnome-disks… there should be an icon called ‘disks’ in your menus… I find it very useful for mounting partitions… but be careful it can alter partitions

Regards
neville

1 Like