I am using Ubuntu 18.04, and trying to moutn Matlab ISO using the following command:
sudo mount R2018a_glnxa64_dvd1.iso /mnt/cdrom -o loop
But terminal is responding back as:
mount: /mnt/cdrom: failed to setup loop device for R2018a_glnxa64_dvd1.iso.
I am not sure as to what this means and how to take it forward.
When I had this problem, I were trying to mount the iso image from a sshfs-mounted directory. After copying the iso image to the local filesystem, it worked.
Create /mnt/cdrom directory first:
mkdir -p /mnt/cdrom
Afterwards mount the iso-image with absolute image path, for example /home/user/R2018a_glnxa64_dvd1.iso instead of just R2018a_glnxa64_dvd1.iso:
sudo mount -o loop /home/user/R2018a_glnxa64_dvd1.iso /mnt/cdrom
If the directory /mnt/cdrom exists, get more info about your iso-image:
file R2018a_glnxa64_dvd1.iso
and try to mount with explicit filesystem type, for example:
sudo mount -o loop -t iso9660 /home/user/R2018a_glnxa64_dvd1.iso /mnt/cdrom
Additionally read my answer at Askubuntu, possibly your image has a boot sector, then mount it with offset option which should be calculated first.
file R2018a_glnxa64_dvd1.iso
/home/user/R2018a_glnxa64_dvd1.iso - not just R2018a_glnxa64_dvd1.iso
mount: /mnt/cdrom: failed to setup loop device for R2018a_glnxa64_dvd1.iso.
I have encountered a very similar problem. Fortunately, the answer of @user3049102 has lead me in the right direction and I have found the explanation.
The problem was with the filesystem where the image file was stored (and it seems to me it could also have been your case).
My issue was with an ISO image on a prototype of a FUSE filesystem. I was not sure if I haven't implemented something or there was some other reason. In fact, the problem is quite simple and well explained but specific to exactly the FUSE-based filesystems (like the mentioned above sshfs, which current implementation is using FUSE). For security reasons, FUSE refuses accessing the files on the mounted filesystem to any other user besides the one who has mounted it. This behaviour can be changed by some FUSE mount options - this is explained on FUSE's gihub - see the section "Security implications".
I guess this may be an issue also with some other filesystems - so if sudo mount ... -o loop fails with its generic error info, the first thing to do is checking if root can access the mounted image file. Then I'd also check if the filesystem where you store the image does not have some specific properties / limitations which may also cause that a file stored there cannot be configured as a loop device.
The simplest solution, as mentioned in the answer about sshfs, is to copy the file to some more "local" filesystem, or - at least in case of ISO images - use eg. fuseiso to mount the image as the same user.
file R2018a_glnxa64_dvd1.iso