Unable to mount UDF filesystem created with mkudffs inside a luks volume

Question

I'm trying to create encrypted blu-ray backup. I've created and burned the image using the following crude 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

When the script is finished I used the following command to burn it to an M-Disc BD-R:

growisofs -dvd-compat -Z /dev/dvd=backup.img

The burn completed without failure. I'm able to open the luks volume 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 the following error:

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

Update 1

Using the following commands I can mount the image produced by the script:

sudo cryptsetup luksOpen backup.img mybackup
sudo mount -t udf /dev/mapper/mybackup /mnt/backup

So something is going wrong because it's on the disc.

Answer 1

The most probable reason for the failure ist the read-only resctriction of the medium when it shall be opened for LUKS.

The experiments below indicate that option -r of cryptsetup does the trick:

sudo cryptsetup luksOpen -r /dev/dvd mybackup
sudo mount -t udf /dev/mapper/mybackup /mnt/backup

---

First wrong theory:

A main difference between optical media and data files or disk devices is the block size of 2048 bytes. E.g. partition editors get confused by this when inspecting the partition tables of isohybrid DVDs. Maybe LUKS is similarly depending on having the same underlying device block size with encryption and decryption.

If you use BD-RE media then you may try whether it helps to create the encrypted filesystem directly on /dev/dvd rather than in file ~/backup.img. (Performance with heavy random access will be poor. Your RAM buffers might push aside other virtual memory and make its using programs act slowly. sync or umount may last quite long.

If you use BD-R, then you could use a BD-RE for creation of the image and then copy it to the BD-R medium.

If nothing works, i could offer the -external_filter feature of xorriso which would encrypt file content while it gets put into an ISO 9660 filesystem with cleartext directory tree. Not the same privacy as with LUKS, but less exotic on the other hand.

(Why in the world do you go for UDF ? Do you have Solaris or BSD machines which might have UDF drivers better than their subterranean ISO 9660 drivers ? Or can the targeted reader systems not use ext ?)

The trace which i should have followed:

Some problem reports in the web about LUKS and CD/DVD/BD advise to use cryptsetup option -r as miracle cure. (I.e. read-only and not the block size would be the stumble stone.)

Making sure that optical media work with LUKS:

I tried the BD-RE part of my proposal to create on a device with 2K blocks (aka sectors). The BD-RE is in /dev/sr4. Setting it up as encrypted disk:

/sbin/cryptsetup luksFormat --cipher aes-xts-plain64 /dev/sr4
sudo /sbin/cryptsetup luksOpen /dev/sr4 mybdre

To avoid the need to be superuser when running xorriso i give the emerged device file to the group "cdrom" where i am member:

chgrp cdrom /dev/dm-0

Using xorriso to write an ISO. You would make an UDF and fill it:

xorriso -for_backup -outdev stdio:/dev/mapper/mybdre -blank as_needed -map /some_directory /

This is darn slow, possibly due to BD-RE Defect Management, which xorriso cannot influence through the crypto device layer. I checkread by tar and (because i have it) by xorriso:

sudo mount /dev/mapper/mybdre /mnt/iso
tar cf - /mnt/iso | wc

No i/o errors, expected size of ISO content is reported.

sudo umount /mnt/iso
xorriso -for_backup -indev stdio:/dev/mapper/mybdre -check_media --

reports MD5 match of the ISO session. So this would work. Now somebody would have to invest a BD-R and copy the BD-RE to it.

Block size difference of disk files and BD does not matter:

I should have tried this first. But now i followed your prescription except that i copied the encrypted image to a BD-RE (still too thrifty for BD-R).

It works. I can mount the BD-RE with -t udf and tar the file contents into wc.

So the hearsay about cryptsetup option -r on read-only media appears to be the only plausible theory left.

Success with a CD-RW as substitute for a BD-R:

I tried with an unformatted CD-RW which is regarded by Linux as read-only.

sudo cryptsetup luksOpen /dev/sr4 mybackup
sudo mount -t udf /dev/mapper/mybackup /mnt/backup

Will never do it again. The drive got dropped by the kernel. One of the /var/log/messages lines says that Linux tried to write to it. Only good it is in an USB box. So i could recover it by a power cycle.

With option -r it works fine:

sudo cryptsetup luksOpen -r /dev/sr4 mybackup
sudo mount -t udf /dev/mapper/mybackup /mnt/backup
tar cf - /mnt/backup | wc

Answer 2

I finally managed to mount the encrypted bluray by first mapping the reader to a loop device and having cryptsetup work on the latter:

sudo losetup /dev/loop0 /dev/dvd
sudo cryptsetup luksOpen /dev/loop0 myvolume
sudo mount /dev/mapper/myvolume /mnt/backup

The encrypted bluray is then mounted at /mnt/backup.

I discovered this in an old Red Hat bug report, and have no idea why the loop device is needed and suspect it could be a bug since automatically mounting using the gui in thunar fails (one would expect that to work) which is also what the Red Hat bug report mentions, albeit with Gnome desktop. It's also very wierd that the image that burns to the bluray can be mounted without the loop device.

To reverse the above, use the following:

sudo umount /mnt/backup
sudo cryptsetup luksClose myvolume
sudo losetup -d /dev/loop0

I opened a bug report with cryptsetup just in case it is a bug.