I am using cryptsetup with detached header. For that I am using the --header parameter, to specify header file. I can open my device using:

cryptsetup luksOpen /dev/sdb1 sdb1 --header LUKS-HEADER

But I need to provide the header not as a file, but as output of another command (I am using cat command for illustration here)

cryptsetup luksOpen /dev/sdb1 sdb1 --header <(cat LUKS-HEADER)

but that does not work. I get following error:

Attaching loopback device failed (loop device with autoclear flag is required).

This is confusing, because similar approach works for providing keys, ie

cryptsetup luksOpen /dev/sdb1 sdb1 --header LUKS-HEADER --key-file <(printf asdf)

the above command works fine (I am using "asdf" as example password).

How can I provide the argument to the --header option from a pipe/another process?

UPDATE for bounty:

the accepted answer works, ie I can use:

cat LUKS-HEADER > /dev/ram0
cryptsetup luksDump /dev/ram0

However, I need a solution how to use process substitution, ie. Currently, process substitution does not work:

cryptsetup luksDump <(cat LUKS-HEADER)

it gives the error:

Attaching loopback device failed (loop device with autoclear flag is required).
  • so dont use that <( thing ) - just use a pipe. – mikeserv Dec 29 '15 at 14:40
  • @mikeserv - please show me how to use pipe with my particular cryptsetup command – Martin Vegter Dec 29 '15 at 14:52
  • printf asdf | cryptsetup /dev/sdb1 sdb1 --header LUKS-HEADER --keyfile /dev/fd/0 – mikeserv Dec 29 '15 at 14:53
  • @mikeserv - I need to provide the header argument from pipe, not the password. – Martin Vegter Dec 29 '15 at 14:57
  • 1
    @MartinVegter Regarding the bounty notice, the --header option does not accept pipes directly (nor Process Substitutions, which are pipes behind-the-scene) because the header needs to be persistent, may be accessed for both reading and writing, in case of LUKS2 also locking, which are all characteristics not supported by pipes. Perhaps if you describe the broader context in which your encrypted disk has to function maybe someone might come up with a workaround, but in the end the backing storage for the header (indicated in --header) has to be either a block-device or a regular file – LL3 Aug 21 '19 at 17:54

It seems that cryptsetup requires the LUKS header to be either regular file or device. If you need to provide the LUKS header as an output from a process/stream, you can easily circumvent the restriction by sending it to /dev/ram

cat LUKS-HEADER > /dev/ram0

(provided that your kernel supports ramdisk)

Then you can then simply use your cryptsetup command as:

cryptsetup luksOpen /dev/sdb1 sdb1 --header /dev/ram0

Keep in mind, the LUKS header will stay in /dev/ram0 disk until you free up the space. To free up the memory, you can use the blockdev command:

blockdev -v --flushbufs /dev/ram0

Cryptsetup (man)

There is no direct solution to pipe the LUKS header data as Cryptsetup --header option is reading a device or a file (cryptsetup.c "header", "Device or file with separated LUKS header"), one potential solution could be opening an issue here asking for the feature. Or may be write a custom patch to cryptsetup to add support for pipe (such solution is not the easiest but it's the most reliable, --header parameter is kept in the variable opt_header_device cryptsetup.c).


To anyone who is trying to fix the error "Attaching loopback device failed (loop device with autoclear flag is required)" when just openining a LUKS device, just run sudo modprobe loop.

It looks like the "loop" module is no longer loaded by default in the newest Linux kernel (5.3.13).


I think whatever you've got going on in <(cat HEADER) isn't actually doing what you think it is. Here are the reasons I believe this:

luksOpen <device> <name> (old syntax)

Opens the LUKS device device and sets up a mapping name after successful verification of the supplied passphrase. If the passphrase is not supplied via --key-file, the command prompts for it interactively.


Cryptsetup is usually used directly on a block device (disk partition or LVM volume). However, if the device argument is a file, cryptsetup tries to allocate a loopback device and map it into this file. This mode requires Linux kernel 2.6.25 or more recent which supports the loop auto-clear flag (loop device is cleared on last close automatically). Of course, you can always map a file to a loop-device manually.

Somehow it appears as if you're generating more arguments than you intend to do, or else less, because, as it would seem, cryptsetup is somehow associating your device argument as a file and not as a block device, and so is trying to mount it via loopback.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.