Cannot format device /dev/sda4 which is still in use

Question

When I try to LUKS encrypt a partition on a CentOS 7 server using the command cryptsetup -y luksFormat /dev/sda4, the attempt fails with the error Cannot format device /dev/sda4 which is still in use. How can I resolve this error and successfully LUKS encrypt the partition?

Here is the terminal record:

[root@localhost ~]# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/dm-1        50G  1.1G   46G   3% /
devtmpfs        3.8G     0  3.8G   0% /dev
tmpfs           3.8G     0  3.8G   0% /dev/shm
tmpfs           3.8G  8.7M  3.8G   1% /run
tmpfs           3.8G     0  3.8G   0% /sys/fs/cgroup
/dev/sda6       296G   65M  281G   1% /vpn
/dev/sda2       477M  110M  338M  25% /boot
/dev/sda1       200M  9.8M  191M   5% /boot/efi
/dev/sda3       596G   73M  565G   1% /home
/dev/sda7       296G   65M  281G   1% /test
/dev/sda5       296G   65M  281G   1% /public
/dev/sda4       296G   65M  281G   1% /data
[root@localhost ~]# cryptsetup -y luksFormat /dev/sda4

WARNING!
========
This will overwrite data on /dev/sda4 irrevocably.

Are you sure? (Type uppercase yes): YES
Enter passphrase: 
Verify passphrase: 
Cannot format device /dev/sda4 which is still in use.

Solution

Is the goal to completely destroy everything on your current /data disk and create a new, entirely empty encrypted volume? Because that's what you're doing with this command. That's what the whole "WARNING: This will overwrite data on /dev/sda4 irrevocably" thing is about. You will lose all the current data, and start over with an empty block device.

More likely, what you want to do is take a data backup of /data, create the new volume, then restore the backup into the new, encrypted filesystem. You can use tar for this nicely:

cd /data
tar czvf /root/data_backup.tar.gz .

Then, and only then, do you write over the filesystem using cryptsetup. The way to get around your error is by unmounting first:

umount /data
cryptsetup -y luksFormat /dev/sda4

Then you can luksOpen the new /dev/sda4, then mkfs onto the encrypted mapping, mount the result, and finally cd into it and restore the existing data with tar.

If you are actually, 100% sure that you want to irrevocably destroy everything in the current /data, then skip the first step, and just jump down to umount /data.

Edit: If you're doing this at all it's possible that the current data is sensitive. If so, consider:

• cryptsetup luksFormat does not overwrite all existing data. It only overwrites the first few KiB. If the data is sensitive you will first want to overwrite all data on the partition, e.g. with wipe, see https://superuser.com/questions/831486/complete-wiping-of-hard-drive-shred-wipe-or-dd. If the partition is large and if there is not much data on the other partitions it will be faster to include all data in a backup on external storage, use the internal disk's "secure erase" feature to blank it in an instant, prepare /data with LUKS and restore your backup.
• To not contaminate /root with the sensitive data, write to a sufficiently large tmpfs, a smaller volume which you can secure-erase afterward or a new filesystem in an encrypted container, or pipe the tar output through gpg before writing the backup.
• cryptsetup-reencrypt can encrypt the data in-place. As the tool is not crash resistant, having a backup is still advisable.

An existing backup becomes the primary copy during the operation. For important data, a second backup should be made so that more than one copy exists at all times.

Comments

[robertspierre]

my volume is unmounted but I still get this error

[Joachim Wagner]

@robertspierre Common reasons: systemd mounting /home again automatically, there is a bind mount of the same volume on another mount point, the volume is part of an md raid or a PV of LVM. What was it in your case (if you can remember 11 months later)?

[robinhoodjr]

@tomhunt why do we do umount /data and not umount /dev/sda4? Does it unmount all other sda* if we do umount /data?

[Tom Hunt]

@robinhoodjr umount /dev/sda4 is equivalent to umount /data in this case, since /dev/sda4 is the device mounted on /data. None of the other /dev/sda* are affected, nor do they matter for this question.