Mounting a luks encrypted udf filesystem from an optical disk fails without loop device
I created a luks encrypted bluray with the following script:
imgsize=23000M
imgfile=~/backup.img
imgloop=`sudo losetup -f`
truncate -s $imgsize $imgfile
sudo losetup $imgloop $imgfile
sudo cryptsetup luksFormat --cipher aes-xts-plain64 $imgloop
sudo cryptsetup luksOpen $imgloop mybackup
sudo mkudffs /dev/mapper/mybackup
if [ ! -d "/mnt/backup" ]; then
sudo mkdir /mnt/backup
fi
sudo mount /dev/mapper/mybackup /mnt/backup
# Now copy all files that are part of the backup
echo "Copy files to backup to /mnt/backup. Type 'ready' when done";
while read line; do
echo "$line";
if [ "$line" == "ready" ]; then
break;
fi
done
sudo umount /mnt/backup
sudo cryptsetup luksClose /dev/mapper/mybackup
sudo losetup -d $imgloop
I burned this to an M-DISC (BD-R) using:
growisofs -dvd-compat -Z /dev/dvd=backup.img
I can open the luks volume without failure using:
sudo cryptsetup luksOpen /dev/dvd mybackup
Which produces the device /dev/mapper/mybackup; however, when I try to mount it with:
sudo mount -t udf /dev/mapper/mybackup /mnt/backup
I get the following error:
mount: /dev/mapper/mybackup is write-protected, mounting read-only
mount: wrong fs type, bad option, bad superblock on /dev/mapper/mybackup,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so.
syslog contains:
[ 2334.880043] UDF-fs: warning (device dm-3): udf_load_vrs: No anchor found
[ 2334.880046] UDF-fs: warning (device dm-3): udf_fill_super: No partition found (1)
The image that I burned, however, can be mounted:
sudo cryptsetup luksOpen backup.img mybackup
sudo mount -t udf /dev/mapper/mybackup /mnt/backup
I eventually discovered that the burned bluray could only be mounted by first mapping the reader to a loop device:
sudo losetup /dev/loop0 /dev/dvd
sudo cryptsetup luksOpen /dev/loop0 myvolume
sudo mount /dev/mapper/myvolume /mnt/backup
I've copied this from my question on superuser.com.
I'm not sure if it's a bug, and if it is, that it's a bug in cryptsetup. I'm only reporting it here because the same bug was reported in Red Hat in 2006, which is where I found the solution to use a loop device.