How to Completely Disable the ‘cryptsetup’ Service in Ubuntu Server

In Ubuntu Server environments, cryptsetup.service (often part of the cryptsetup-initramfs or standard cryptsetup package) is responsible for mapping and unlocking LUKS (Linux Unified Key Setup) encrypted block devices during the boot sequence or when hot-plugging drives. It reads from /etc/crypttab to determine which encrypted partitions need to be initialized. While Full Disk Encryption (FDE) is standard practice for laptops and physical servers deployed in unsecure locations, a heavily fortified, physically secure data center deploying ephemeral VMs or cloud instances often relies on storage-level encryption provided by the hypervisor (e.g., AWS EBS encryption). On these systems, the OS-level cryptsetup daemon is redundant, adds unnecessary overhead, and can delay boot times if it attempts to parse empty or misconfigured crypttab files.

This guide explains how to completely disable the cryptsetup services in Ubuntu Server, ensuring the OS never attempts to manage LUKS volumes directly.

Stop and Mask the Cryptsetup Services

Because the cryptsetup framework consists of multiple target units and generator scripts tied to the early boot process, we must mask the primary target to ensure systemd ignores any encrypted volume requests entirely.

1. Log into your Ubuntu Server via SSH using an account with sudo privileges.
2. First, ensure that your root filesystem (/) or any critical mount points (like /var or /home) are not currently relying on LUKS encryption. Disabling this service on an encrypted system will render it unbootable. Check with lsblk -f.
3. To prevent systemd from processing encrypted volumes, disable and mask the primary cryptsetup target:

   sudo systemctl disable cryptsetup.target

4. Next, explicitly mask the target to prevent it from being invoked by any dependencies:

   sudo systemctl mask cryptsetup.target

Verify the Service Lockdown

By masking cryptsetup.target, you have instructed systemd to symlink the unit to /dev/null, effectively castrating the OS’s ability to map LUKS containers automatically.

To verify the lockdown is successful, run the following command to check the status of the target:

systemctl status cryptsetup.target

The output will clearly state that the target is masked. If you attempt to add an entry to /etc/crypttab and run systemctl daemon-reload, systemd will ignore the generator request because the parent target is blackholed. Your server is now streamlined to rely exclusively on unencrypted block devices or hypervisor-level storage encryption.