0

I have a bash script where I mount an ISO to loop devices:

mount -o loop my.iso /tmp/foo

And it happens that at the same time in my OS (Linux Mint 19) I have an ISO image mounted, using the GUI option for this action.

So I get the error

mount: /tmp/foo: /dev/loop0 ya está montado o el punto de montaje está ocupado.

(...loop0 mount point busy...)

Question:

Can I select what loop can I mount my ISO, something like:

mount - loop3 my.iso /tmp/foo

so I don't need to umount the previous ISO?

  • @炸鱼薯条德里克 not really ;-) – mosvy May 23 at 22:57
  • @炸鱼薯条德里克 well, my assumption was completely dumb, no need to argue about it. – mosvy May 23 at 23:10
  • Is /tmp/foo a directory? What about ownership and permissions? Are you mounting with root privileges (logged in as root or with sudo)? – sudodus May 24 at 6:54
  • @sudodus /tmp/foo is a directory and I run the script as sudo. – guillermo chamorro May 24 at 11:21
  • You could always manually set up the loop device first with losetup – ivanivan May 24 at 12:47
3

The error is not because you already have another ISO device mounted; the mount -o loop will always get the first unused loop device or create a new one.

And it's not because the same ISO image / loop device is already mounted on another directory -- the same device can be mounted on different mount points at the same time.

What you're probably trying to do is mount the same ISO on the same mount point twice. The mount(8) utility will try to guard you against that by checking if the backing file is already attached to a loop device and reusing that device, instead of attaching the same file to multiple loop devices.

But if you really want to do that, you can bypass the check by attaching the loop device by hand with losetup:

# mount -o ro a.iso dir/

# mount -o ro a.iso dir/
mount: /tmp/a.iso is already mounted

# losetup --show -f a.iso
/dev/loop1
# mount -o ro /dev/loop1 dir/
# 

The two combined:

# dev=$(losetup --show -f a.iso) && { mount -o ro "$dev" dir/ || losetup -d "$dev"; }

You should then use the -d option of umount(8) explicitly, or detach the the loop by hand afterwards, with losetup -d:

# umount -d dir/

That should be pretty safe with read-only filesystems, like ISOs. Don't ever use it with filesystems mounted in read-write mode.

  • Good answer talking about extra behavior of mount utility. But I'm still wondering how does it do this? Is there any ioctl can detect the underlying file of a loop device? What if the underlying file just change name, or get deleted, or get over mounted. – 炸鱼薯条德里克 May 25 at 3:57
  • Yes, there is -- look at the loop(5) manpage. Part of that info is also available via /sys/block/7:X/loop/. A loop device is not attached to a directory entry but to a file/inode. mount(8) checks via the dev:inode pair, and won't be fooled by name changes, etc. – mosvy May 25 at 6:37
  • The kernel also keeps the name of backing file, but it's purely informative: while the kernel is able to track the name through rename(2)s, it will be fooled by a ln + rm, or by bind mounts (just like the /proc/PID/fd/FD symlink targets). – mosvy May 25 at 6:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.