Issue with AzureDiskEncryptionForLinux extension

Question

Hi,

I'm having problems getting AzureDiskEncryptionForLinux to work. We have VMs running a custom gallery image based on the official Ubuntu images.

It looks like in the end ADE does get enabled after a while. The extension does give an error

Failed to encrypt data volumes with error: Encryption failed for name:sdd1 type:part fstype:ext4 mountpoint:/data label:data model: size:134215630848 majmin:8:49 device_id:f8b3781b-1e82-4818-a1c3-63d806ec15bb, stack trace: Traceback (most recent call last): File "/var/lib/waagent/Microsoft.Azure.Security.AzureDiskEncryptionForLinux-1.4.0.10/main/handle.py", line 2171, in daemon_encrypt while not daemon_encrypt_data_volumes(encryption_marker=encryption_marker, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/var/lib/waagent/Microsoft.Azure.Security.AzureDiskEncryptionForLinux-1.4.0.10/main/handle.py", line 2437, in daemon_encrypt_data_volumes raise Exception(message) Exception: Encryption failed for name:sdd1 type:part fstype:ext4 mountpoint:/data label:data model: size:134215630848 majmin:8:49 device_id:f8b3781b-1e82-4818-a1c3-63d806ec15bb

Is there a way to make this extension more stable? Is there an alternative way to enable ADE without going through the extension, for instance at image build time?

Best regards,

Jelle

Answer 1

Hi,

If you are having problems with the extension that you cannot resolve via troubleshooting may be you should look at using Encryption at host instead of Azure disk encryption. Encryption cannot be achieved at image build time as the point of the image is to contain common settings for your VMs where encryption is strictly individual per VM setting.

Please "Accept the answer" if the information helped you. This will help us and others in the community as well.

Answer 2

Hi, the “Failed to encrypt data volumes … fstype: ext4” error usually occurs when Azure Disk Encryption (ADE) prerequisites aren't fully met. First, make sure both the Azure Linux Agent is version 2.2.53+ and the ADE extension is 1.4.0.10 GA or later, older versions often cause silent failures or false error codes. ADE needs a few megabytes of free space to shrink and re-expand the ext4 partition when injecting the LUKS header, so ensure the target volume (e.g., /data) has at least 5% free (or ~200MB) and non-zero reserved blocks; otherwise, resize2fs will fail. Also, if services like Docker, databases, or log collectors are holding the mount, the unmount step fails, stop them before running ADE, or use the --encrypt-format-all option to wipe and encrypt the disk without shrinking. Keep in mind that custom images are not officially supported unless you built them using Microsoft’s pre-encryption guidance—custom layouts often lead to inconsistent ADE behavior. If you want to avoid the ADE extension entirely, consider alternatives: Encryption at Host (I/O encrypted at the hypervisor level, no guest agent), SSE with CMK (customer-managed keys with Disk Encryption Set), or pre-encrypted VHDs (OS/data pre-encrypted during image build). To quickly fix issues: update the agent and extension, free up space on /data, stop blocking services, and rerun the encryption using az vm encryption enable with --volume-type DATA. Monitor progress with az vm encryption show, where the status should go from Transitioning to Provisioning succeeded within minutes. Let me know if you need a Docker-safe helper script or an example Packer config for pre-encrypted gallery images.