A mkfs.btrfs error: "ERROR: error during mkfs: Operation not permitted" when formating an encrypted (LUKS) disk with BTRFS format

Ask Fedora
1

I bought an external SSD (2 Tera Byte), called “WD My Passport SSD 2TB Mobile SSD Storage”.

I am trying to encrypt with LUKS and format the storage device with BTRFS format on Fedora Linux 39. I referred to Fedora’s document[1], and my past article blog article about encrypting and encrypting with LUKS and formatting 1 TB HDD with BTRFS[2].

Then I got an error. Let me explain it.

As an initial state, the SSD was detected as /dev/sda1 with the label by the lsblk command.

$ lsblk -r -p -o NAME,TYPE,FSTYPE,UUID,SIZE,LABEL
...
/dev/sda disk   1.8T
/dev/sda1 part exfat BAB8-C8F1 1.8T My\x20Passport
...

Following the [1], as preparation before formatting the SSD, I filled random data into the storage device.

$ sudo badblocks -c 10240 -s -w -t random -v /dev/sda1

Then, I formatted the storage device.

$ sudo cryptsetup luksFormat /dev/sda1
...
Are you sure? (Type 'yes' in capital letters): YES
Enter passphrase for /dev/sda1:
Verify passphrase:
...

Then, I created a mapping to allow access to the device’s decrypted contents.

$ sudo cryptsetup luksUUID /dev/sda1
c522db23-e751-4fa6-a9a6-a45dc06878fc

$ sudo cryptsetup luksOpen /dev/sda1 luks-c522db23-e751-4fa6-a9a6-a45dc06878fc

Below is the information about the mapped device.

$ sudo dmsetup info luks-c522db23-e751-4fa6-a9a6-a45dc06878fc
Name:              luks-c522db23-e751-4fa6-a9a6-a45dc06878fc
State:             ACTIVE
Read Ahead:        4096
Tables present:    LIVE
Open count:        0
Event number:      0
Major, minor:      253, 1
Number of targets: 1
UUID: CRYPT-LUKS2-c522db23e7514fa6a9a6a45dc06878fc-luks-c522db23-e751-4fa6-a9a6-a45dc06878fc

Then I got the following error when trying to format the storage with BTRFS.

$ sudo mkfs.btrfs -L my-passport-ssd-2tb /dev/mapper/luks-c522db23-e751-4fa6-a9a6-a45dc06878fc
btrfs-progs v6.7.1
See https://btrfs.readthedocs.io for more information.

NOTE: several default settings have changed in version 5.15, please make sure
      this does not affect your deployments:
      - DUP for metadata (-m dup)
      - enabled no-holes (-O no-holes)
      - enabled free-space-tree (-R free-space-tree)
ERROR: error during mkfs: Operation not permitted

Now I noticed the /dev/sda and /dev/sda1 lines disappeared in the output of the following lsblk command.

$ lsblk -r -p -o NAME,TYPE,FSTYPE,UUID,SIZE,LABEL

Do you have any ideas about how to fix the error by the above mkfs.btrfs command?

Thanks for your help!

2

I rebooted the OS. The /dev/sda and /dev/sda1 appeared again by the lsblk command.

$ lsblk -r -p -o NAME,TYPE,FSTYPE,UUID,SIZE,LABEL
NAME TYPE FSTYPE UUID SIZE LABEL
/dev/sda disk   1.8T
/dev/sda1 part crypto_LUKS c522db23-e751-4fa6-a9a6-a45dc06878fc 1.8T
/dev/zram0 disk   8G
/dev/nvme0n1 disk   1.8T
/dev/nvme0n1p1 part vfat D0B0-4455 600M
/dev/nvme0n1p2 part ext4 1072bb16-2ca1-4502-8bda-750ad467f25f 1G
/dev/nvme0n1p3 part crypto_LUKS 09538e5a-f802-40a6-bc22-328604dc2312 1.8T
/dev/mapper/luks-09538e5a-f802-40a6-bc22-328604dc2312 crypt btrfs be430ab5-ebda-4f4f-a01e-427d18fb12f1 1.8T fedora_localhost-live

$ sudo cryptsetup luksOpen /dev/sda1 luks-c522db23-e751-4fa6-a9a6-a45dc06878fc
Enter passphrase for /dev/sda1:

The lsblk still showed the /dev/sda and /dev/sda1.

$ lsblk -r -p -o NAME,TYPE,FSTYPE,UUID,SIZE,LABEL
NAME TYPE FSTYPE UUID SIZE LABEL
/dev/sda disk   1.8T
/dev/sda1 part crypto_LUKS c522db23-e751-4fa6-a9a6-a45dc06878fc 1.8T
/dev/mapper/luks-c522db23-e751-4fa6-a9a6-a45dc06878fc crypt   1.8T
/dev/zram0 disk   8G
/dev/nvme0n1 disk   1.8T
/dev/nvme0n1p1 part vfat D0B0-4455 600M
/dev/nvme0n1p2 part ext4 1072bb16-2ca1-4502-8bda-750ad467f25f 1G
/dev/nvme0n1p3 part crypto_LUKS 09538e5a-f802-40a6-bc22-328604dc2312 1.8T
/dev/mapper/luks-09538e5a-f802-40a6-bc22-328604dc2312 crypt btrfs be430ab5-ebda-4f4f-a01e-427d18fb12f1 1.8T fedora_localhost-live

Another error “ERROR: superblock magic doesn’t match” was printed with the “ERROR: error during mkfs: Operation not permitted”.

$ ls -l /dev/mapper/luks-c522db23-e751-4fa6-a9a6-a45dc06878fc
lrwxrwxrwx. 1 root root 7 Sep 27 23:25 /dev/mapper/luks-c522db23-e751-4fa6-a9a6-a45dc06878fc -> ../dm-1

$ sudo mkfs.btrfs -L my-passport-ssd-2tb /dev/mapper/luks-c522db23-e751-4fa6-a9a6-a45dc06878fc
btrfs-progs v6.7.1
See https://btrfs.readthedocs.io for more information.

ERROR: superblock magic doesn't match
NOTE: several default settings have changed in version 5.15, please make sure
      this does not affect your deployments:
      - DUP for metadata (-m dup)
      - enabled no-holes (-O no-holes)
      - enabled free-space-tree (-R free-space-tree)


ERROR: error during mkfs: Operation not permitted

The /dev/sda and /dev/sda1 disappeared.

$ lsblk -r -p -o NAME,TYPE,FSTYPE,UUID,SIZE,LABEL
NAME TYPE FSTYPE UUID SIZE LABEL
/dev/zram0 disk   8G
/dev/nvme0n1 disk   1.8T
/dev/nvme0n1p1 part vfat D0B0-4455 600M
/dev/nvme0n1p2 part ext4 1072bb16-2ca1-4502-8bda-750ad467f25f 1G
/dev/nvme0n1p3 part crypto_LUKS 09538e5a-f802-40a6-bc22-328604dc2312 1.8T
/dev/mapper/luks-09538e5a-f802-40a6-bc22-328604dc2312 crypt btrfs be430ab5-ebda-4f4f-a01e-427d18fb12f1 1.8T fedora_localhost-live
3

Added btrfs

4

btrfs-progs 6.7.1 is kinda old, current Fedora 39 btrfs-progs is 6.11. Maybe there’s a bug that’s been fixed since the older version? I suggest dnf update or at least make sure kernel, btrfs-progs, and cryptsetup are all up to date.

If you still get the error, looks to me like the drive is vanishing off the USB bus for some reason. Please run this command:

journalctl -k -o short-monotonic --no-hostname | fpaste

And post the URL.

5

Thanks for your advice! For the record, I was using the following packages. I will upgrade, and try it again.

$ uname -r
6.7.9-200.fc39.x86_64

$ rpm -q kernel
kernel-6.4.15-200.fc38.x86_64
kernel-6.7.9-100.fc38.x86_64
kernel-6.7.9-200.fc39.x86_64

$ rpm -q btrfs-progs
btrfs-progs-6.7.1-1.fc39.x86_64

$ rpm -q cryptsetup
cryptsetup-2.6.1-3.fc39.x86_64
6

Also, I’m curious if mkfs.ext4 works? Or if the USB drive also vanishes following that command?

7

Still another idea is to use mkfs.btrfs -vvv --nodiscard and see if that works? And if not the multiple v’s will add some verbose messages, hopefully providing a hint why it fails.

8

I ran the dnf upgrade and restarted the OS. Then below are the RPM packages.

$ uname -r
6.10.11-100.fc39.x86_64

$ rpm -q kernel
kernel-6.7.9-100.fc38.x86_64
kernel-6.7.9-200.fc39.x86_64
kernel-6.10.11-100.fc39.x86_64

$ rpm -q btrfs-progs
btrfs-progs-6.10.1-1.fc39.x86_64

$ rpm -q cryptsetup
cryptsetup-2.6.1-3.fc39.x86_64

Then I got the same error with the previous one below.

$ lsblk -r -p -o NAME,TYPE,FSTYPE,UUID,SIZE,LABEL
NAME TYPE FSTYPE UUID SIZE LABEL
/dev/sda disk   1.8T
/dev/sda1 part crypto_LUKS c522db23-e751-4fa6-a9a6-a45dc06878fc 1.8T
/dev/zram0 disk   8G
/dev/nvme0n1 disk   1.8T
/dev/nvme0n1p1 part vfat D0B0-4455 600M
/dev/nvme0n1p2 part ext4 1072bb16-2ca1-4502-8bda-750ad467f25f 1G
/dev/nvme0n1p3 part crypto_LUKS 09538e5a-f802-40a6-bc22-328604dc2312 1.8T
/dev/mapper/luks-09538e5a-f802-40a6-bc22-328604dc2312 crypt btrfs be430ab5-ebda-4f4f-a01e-427d18fb12f1 1.8T fedora_localhost-live

$ sudo cryptsetup luksUUID /dev/sda1
c522db23-e751-4fa6-a9a6-a45dc06878fc

$ sudo cryptsetup luksOpen /dev/sda1 luks-c522db23-e751-4fa6-a9a6-a45dc06878fc
Enter passphrase for /dev/sda1:

$ sudo dmsetup info luks-c522db23-e751-4fa6-a9a6-a45dc06878fc
Name:              luks-c522db23-e751-4fa6-a9a6-a45dc06878fc
State:             ACTIVE
Read Ahead:        4096
Tables present:    LIVE
Open count:        0
Event number:      0
Major, minor:      253, 1
Number of targets: 1
UUID: CRYPT-LUKS2-c522db23e7514fa6a9a6a45dc06878fc-luks-c522db23-e751-4fa6-a9a6-a45dc06878fc

$ sudo mkfs.btrfs -L my-passport-ssd-2tb /dev/mapper/luks-c522db23-e751-4fa6-a9a6-a45dc06878fc
btrfs-progs v6.10.1
See https://btrfs.readthedocs.io for more information.

ERROR: superblock magic doesn't match
Performing full device TRIM /dev/mapper/luks-c522db23-e751-4fa6-a9a6-a45dc06878fc (1.82TiB) ...
NOTE: several default settings have changed in version 5.15, please make sure
      this does not affect your deployments:
      - DUP for metadata (-m dup)
      - enabled no-holes (-O no-holes)
      - enabled free-space-tree (-R free-space-tree)


ERROR: error during mkfs: Operation not permitted

The journal log is https://paste.centos.org/view/64d732d5.

$ journalctl -k -o short-monotonic --no-hostname | fpaste

https://paste.centos.org/view/64d732d5
9

I rebooted the OS before trying the following commands with the mkfs.ext4. It didn’t work as well with showing an error.

First, after rebooting the OS, I inserted the external SSD, and confirmed that /dev/sda and /dev/sda1 existed.

$ lsblk -r -p -o NAME,TYPE,FSTYPE,UUID,SIZE,LABEL
NAME TYPE FSTYPE UUID SIZE LABEL
/dev/sda disk   1.8T
/dev/sda1 part crypto_LUKS c522db23-e751-4fa6-a9a6-a45dc06878fc 1.8T
/dev/zram0 disk   8G
/dev/nvme0n1 disk   1.8T
/dev/nvme0n1p1 part vfat D0B0-4455 600M
/dev/nvme0n1p2 part ext4 1072bb16-2ca1-4502-8bda-750ad467f25f 1G
/dev/nvme0n1p3 part crypto_LUKS 09538e5a-f802-40a6-bc22-328604dc2312 1.8T
/dev/mapper/luks-09538e5a-f802-40a6-bc22-328604dc2312 crypt btrfs be430ab5-ebda-4f4f-a01e-427d18fb12f1 1.8T fedora_localhost-live

Then I ran the cryptsetup luksOpen.

$ sudo cryptsetup luksOpen /dev/sda1 luks-c522db23-e751-4fa6-a9a6-a45dc06878fc
Enter passphrase for /dev/sda1:

The mkfs.ext4 finished with an error.

$ rpm -qf /usr/sbin/mkfs.ext4
e2fsprogs-1.47.0-2.fc39.x86_64

$ sudo mkfs.ext4 /dev/mapper/luks-c522db23-e751-4fa6-a9a6-a45dc06878fc
mke2fs 1.47.0 (5-Feb-2023)
Creating filesystem with 488365844 4k blocks and 122093568 inodes
Filesystem UUID: d0ccad7d-be2e-407a-8299-cb0e608cf940
Superblock backups stored on blocks:
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
	4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
	102400000, 214990848

Allocating group tables: done
Writing inode tables: done
Creating journal (262144 blocks): done
Writing superblocks and filesystem accounting information: mkfs.ext4: Input/output error while writing out and closing file system

$ echo $?
1

The /dev/sda and /dev/sda1 disappeared from the output of the lsblk.

$ lsblk -r -p -o NAME,TYPE,FSTYPE,UUID,SIZE,LABEL
NAME TYPE FSTYPE UUID SIZE LABEL
/dev/zram0 disk   8G
/dev/nvme0n1 disk   1.8T
/dev/nvme0n1p1 part vfat D0B0-4455 600M
/dev/nvme0n1p2 part ext4 1072bb16-2ca1-4502-8bda-750ad467f25f 1G
/dev/nvme0n1p3 part crypto_LUKS 09538e5a-f802-40a6-bc22-328604dc2312 1.8T
/dev/mapper/luks-09538e5a-f802-40a6-bc22-328604dc2312 crypt btrfs be430ab5-ebda-4f4f-a01e-427d18fb12f1 1.8T fedora_localhost-live

Below is the link to the journalctl.

$ journalctl -k -o short-monotonic --no-hostname | fpaste
Uploading (131.7KiB)...
https://paste.centos.org/view/257d05be
10

OK. I tried the command too below.

First, I rebooted the OS to show the /dev/sda and /dev/sda1 in the result of the lsblk, and ran the cryptsetup luksOpen.

$ lsblk -r -p -o NAME,TYPE,FSTYPE,UUID,SIZE,LABEL
NAME TYPE FSTYPE UUID SIZE LABEL
/dev/sda disk   1.8T
/dev/sda1 part crypto_LUKS c522db23-e751-4fa6-a9a6-a45dc06878fc 1.8T
/dev/zram0 disk   8G
/dev/nvme0n1 disk   1.8T
/dev/nvme0n1p1 part vfat D0B0-4455 600M
/dev/nvme0n1p2 part ext4 1072bb16-2ca1-4502-8bda-750ad467f25f 1G
/dev/nvme0n1p3 part crypto_LUKS 09538e5a-f802-40a6-bc22-328604dc2312 1.8T
/dev/mapper/luks-09538e5a-f802-40a6-bc22-328604dc2312 crypt btrfs be430ab5-ebda-4f4f-a01e-427d18fb12f1 1.8T fedora_localhost-live

$ sudo cryptsetup luksOpen /dev/sda1 luks-c522db23-e751-4fa6-a9a6-a45dc06878fc
Enter passphrase for /dev/sda1:

Then I got the following error “checksum verify failed”.

$ sudo mkfs.btrfs -L my-passport-ssd-2tb -vvv --nodiscard /dev/mapper/luks-c522db23-e751-4fa6-a9a6-a45dc06878fc
btrfs-progs v6.10.1
See https://btrfs.readthedocs.io for more information.

NOTE: several default settings have changed in version 5.15, please make sure
      this does not affect your deployments:
      - DUP for metadata (-m dup)
      - enabled no-holes (-O no-holes)
      - enabled free-space-tree (-R free-space-tree)

checksum verify failed on 1081344 wanted 0xf6e2b79f found 0xefa6c526
ERROR: cannot read chunk root
ERROR: open ctree failed

$ echo $?
1

The journal log is below.

$ journalctl -k -o short-monotonic --no-hostname | fpaste
Uploading (121.0KiB)...
https://paste.centos.org/view/43049829

Interestingly, the /dev/sda and /dev/sda1 still appear after the above commands.

$ lsblk -r -p -o NAME,TYPE,FSTYPE,UUID,SIZE,LABEL
NAME TYPE FSTYPE UUID SIZE LABEL
/dev/sda disk   1.8T
/dev/sda1 part crypto_LUKS c522db23-e751-4fa6-a9a6-a45dc06878fc 1.8T
/dev/mapper/luks-c522db23-e751-4fa6-a9a6-a45dc06878fc crypt   1.8T
/dev/zram0 disk   8G
/dev/nvme0n1 disk   1.8T
/dev/nvme0n1p1 part vfat D0B0-4455 600M
/dev/nvme0n1p2 part ext4 1072bb16-2ca1-4502-8bda-750ad467f25f 1G
/dev/nvme0n1p3 part crypto_LUKS 09538e5a-f802-40a6-bc22-328604dc2312 1.8T
/dev/mapper/luks-09538e5a-f802-40a6-bc22-328604dc2312 crypt btrfs be430ab5-ebda-4f4f-a01e-427d18fb12f1 1.8T fedora_localhost-live
11

First indication of a device or connection problem:

[15545.899008] kernel: scsi 0:0:0:1: Failed to get diagnostic page 0x1
[15545.899013] kernel: scsi 0:0:0:1: Failed to bind enclosure -19
[15545.899028] kernel: ses 0:0:0:1: Attached Enclosure device
[16019.641158] kernel: sd 0:0:0:0: [sda] tag#20 uas_eh_abort_handler 0 uas-tag 21 inflight: CMD OUT 
[16019.641174] kernel: sd 0:0:0:0: [sda] tag#20 CDB: Write(10) 2a 00 00 00 95 d0 00 00 06 00

…

[16021.998089] kernel: scsi host0: uas_eh_device_reset_handler start

…

[16041.271039] kernel: scsi host0: uas_eh_device_reset_handler FAILED err -19
[16041.271049] kernel: sd 0:0:0:0: Device offlined - not ready after error recovery

This gist of all that is the device it confused and stops responding. That’s why it works after a reboot, or if you just unplug the device from USB and then plug it back in.

What’s the solution? Well, I’m not sure if this is a uas incompatibility problem, or a bus power problem. You might have to try both.

I use an externally powered hub for my USB drives in enclosures and it solved all problems. But it’s possible in your case that won’t work, so I suggest borrowing a powered USB hub to see if it fixes the problem or not before you buy one.

Another possibility is disabling UAS. It’s possible to disable it entirely for all devices, or set a quirk for the specific drive you’re working with, and then uas is only disabled for that device.

More here: