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.
[ 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.