Hi, B.M. wrote: > file "$IMGFILE" > LUKS encrypted file, ver 2 [, , sha256] UUID: > 835847ff-2cb3-4c6d-aa04-d3b79010a2d3
So it did not stay unencrypted by mistake. (I assume this is one of the unreadable images.) > mount -t udf -o novrs /dev/mapper/BDbackup /mnt/BDbackup > [62614.207920] UDF-fs: warning (device dm-10): udf_load_vrs: No anchor found > [62614.207922] UDF-fs: Scanning with blocksize 2048 failed > So now I'm stuck again, but maybe one little step later... Yeah. Reading the anchor is a little bit further in the procedure. But already the missing VRS is a clear indication that the image or disc does not get properly decrypted when being mounted for reading. The VRS was there when it was mounted for writing. Later it's gone. A UDF filesystem image is supposed to bear at its start 32 KiB of zeros. Have a look with a hex dumper or editor at /dev/mapper/BDbackup. If you see something heavily non-zero, then decryption is the main suspect. > Thanks again for any hints... As said, i would try whether UDF works fine without encryption. If yes, i would try whether dd-ing an unencryptedly populated UDF image into /dev/mapper/BDbackup yields images which are more reliably readable. If UDF does not work even unencrypted, then i'd consider ext2 or ISO 9660 as alternatives. (ext2 would be treated like UDF. For ISO 9660 i'd propose xorriso and directing its output to the not mounted /dev/mapper/BDbackup.) Have a nice day :) Thomas