Kernel 6.18.x and 6.19.0-rc5 fail to suspend (hang) if any VeraCrypt volume is mounted

[nsleasy]

Laptop fails to enter Suspend mode with all versions of Kernel 6.18 and Kernel 6.19.0-rc5 if any VeraCrypt volume is mounted. This is true whether the VeraCrypt volume is partition-based or file-based. All previous kernels, including 6.17 are fine.

Expected behavior

Laptop power light goes out
Disk activity light goes out
Laptop (Linux kernel) suspend normally

Observed behavior

Power light remains on
Disk activity light remains on
Laptop (Linux kernel) fails to suspend

Steps to reproduce

1. Mount any VeraCrypt volume normally
2. Issue suspend command ('systemctl suspend') or suspend from the desktop environment

Screenshots

N/A

Your Environment

VeraCrypt version:
1.26.24 (But also occurs using 1.26.14

Hardware:
Lenovo IdeaPad 5 15ITL05
11th Gen Intel® Core™ i5-1135G7 × 4
8.0 GiB Memory
Intel® Iris® Xe Graphics (TGL GT2)

Operating Environment:
Firmware ver: FHCN78WW
openSUSE Tumbleweed
64-bit
GNOME 49 Wayland
Linux 6.18.5-1-default

Additional Notes

I have opened the following bug reports, thinking that this is a kernel bug. However, they seem to believe that it is a a VeraCrypt bug. Assistance is needed in tracking down the problem in any case.

https://bugzilla.kernel.org/show_bug.cgi?id=220996

https://bugzilla.opensuse.org/show_bug.cgi?id=1256893

[marcusxss]

Experiencing the same thing, and on different hardware (ASUS) and distro.

Same kernel versions.

Edit: In our case it's mounted with cryptsetup (which has veracrypt support) - not veracrypt itself.
Is that the same for you?

[bog-god]

Experiencing the same thing, and on different hardware (ASUS) and distro.

Same kernel versions.

Edit: In our case it's mounted with cryptsetup (which has veracrypt support) - not veracrypt itself. Is that the same for you?

Tried cryptsetup and it acts the same way as veracrypt, as expected on kernel before 6.18 but doesn't wake up from suspend on any newer kernels.

[owsma]

Same here on Asus hardware, GNOME 49.5, Kernel 6.19.10-200.

Below are potentially relevant jounalctl lines, where the system hung at 16:57. I think 17:04 might be when I tried the power button to suspend. The first line seems to come up at almost every suspend, regardless of the issue.

Apr 02 16:56:59 gsd-power[4085]: g_variant_new_string: assertion 'string != NULL' failed
Apr 02 16:57:56 wpa_supplicant[1841]: wlp98s0: RSN: Group rekeying completed with 3c:37:12:c4:22:bf [GTK=CCMP]
Apr 02 17:01:00 CROND[41236]: (root) CMD (run-parts /etc/cron.hourly)
Apr 02 17:01:00 run-parts[41239]: (/etc/cron.hourly) starting 0anacron
Apr 02 17:01:00 run-parts[41245]: (/etc/cron.hourly) finished 0anacron
Apr 02 17:01:00 CROND[41235]: (root) CMDEND (run-parts /etc/cron.hourly)
Apr 02 17:04:29 kernel: Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
Apr 02 17:04:29 kernel: Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
Apr 02 17:04:29 systemd-logind[1578]: The system will suspend now!
Apr 02 17:04:29 ModemManager[1643]: [sleep-monitor-systemd] system is about to suspend
Apr 02 17:04:29 ModemManager[1643]: [sleep-monitor-systemd] ready to sleep; dropping inhibitor
Apr 02 17:04:29 NetworkManager[1699]: [1775142269.7097] manager: sleep: sleep requested (sleeping: no enabled: yes)
Apr 02 17:04:29 NetworkManager[1699]: [1775142269.7100] device (p2p-dev-wlp98s0): state change: disconnected -> unmanaged (reason 'unmanaged-nm-disabled', managed-type: 'full')
Apr 02 17:04:29 NetworkManager[1699]: [1775142269.7104] manager: NetworkManager state is now DISABLED (ASLEEP)

[idrassi]

Thanks everyone for the reports and the additional details.

Based on the details shared here and the information in the linked bugs, this does not look directly caused by VeraCrypt. It looks more like a Linux suspend interaction issue involving ntfs-3g/fuseblk.

A plausible failure path is the following deadlock:

1. systemd-sleep freezes user sessions before suspend.
2. A FUSE userspace filesystem daemon such as ntfs-3g is frozen.
3. The kernel suspend path tries to sync or otherwise access mounted filesystems.
4. The FUSE filesystem needs its userspace daemon to respond, but that daemon is frozen.
5. Suspend waits indefinitely.

This would also explain why similar behavior can occur with plain FUSE/ntfs-3g mounts unrelated to VeraCrypt:
https://bbs.archlinux.org/viewtopic.php?pid=2288750

To confirm this hypothesis, does the issue also occur with a VeraCrypt volume formatted as ext4?

As a diagnostic workaround, please try disabling systemd user-session freezing for suspend:

sudo mkdir -p /etc/systemd/system/systemd-suspend.service.d
sudo tee /etc/systemd/system/systemd-suspend.service.d/10-no-freeze-user-sessions.conf >/dev/null <<'EOF'
[Service]
Environment=SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=false
EOF

sudo systemctl daemon-reload
systemctl suspend

Does this workaround avoid the suspend hang?

[marcusxss]

In our case it could indeed actually be ntfs-3g related instead.
Good call!

From a couple of tests it also seems like your workaround works, testing with an ntfs-3g vecacrypt volume and your workaround. Haven't tried a veracrypt ext4 container yet.

Thank you!

Edit: Scratch that test, because I just tried to disable the fix and reboot, mount veracrypt ntfs-3g and suspend and it worked.

So it seems in my case, in Linux 6.19.11 it might just be working again now?
ntfs-3g has not been updated in years so that can't be it. The version is 2022.10.3-2
fuse-common is 3.18.2-1, built in 2026-03-20, so that's quite new.

So I guess from my test it's uncertain if the fix works or not.

This was on Arch, so it's possible a fix was added to arch since the linked bug report is precisely the arch forums.

Edit: Typo in the kernel version

[idrassi]

@marcusxss
Thanks for testing and for the update.
If the SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=false workaround is not active and suspend now works, then clearly upstream issue has been fixed by Arch somehow.

Feedback from users on other distributions will give us a clearer picture.

[idrassi]

Thanks @abhinavagarwal07 for the PR and for pointing to the two relevant upstream changes. I closed the PR because the implementation is not mergeable as-is but the pointers were useful.

After checking the upstream systemd and kernel sources, I think the root-cause hypothesis is getting clearer:

1. systemd now freezes user.slice during sleep handling, but this is not an upstream systemd v255 change. The "always freeze
   user.slice" change is systemd commit 0b958bb3eeae61dd25a1f6735477ea239981b162, released in systemd v256: systemd/systemd@0b958bb

2. Linux 6.18 commit d3906d8f3cee0279d459dc88b5a871fcdcd4b236 did enable FUSE_SYNCFS for all fuseblk mounts: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d3906d8f3cee0279d459dc88b5a871fcdcd4b236

3. The suspend path performs filesystem sync before the kernel enters the rest of suspend. If systemd has already frozen user.slice
   and the mounted filesystem is handled by a userspace FUSE daemon in that slice, then the kernel can end up waiting for a FUSE reply from a process that cannot run.

So the plausible failure path is:

1. A VeraCrypt volume is mounted.
2. The filesystem inside the volume is NTFS and is mounted via ntfs-3g, which appears as fuseblk.
3. systemctl suspend starts.
4. systemd freezes user.slice.
5. ntfs-3g, running under the user session, is frozen.
6. The kernel suspend path syncs filesystems.
7. Since Linux 6.18, fuseblk sync can issue FUSE_SYNCFS.
8. The kernel waits for the FUSE daemon, but the daemon is frozen.
9. Suspend hangs.

This also explains why similar behavior was reported when using cryptsetup with VeraCrypt support, and why plain ntfs-3g/
fuseblk mounts unrelated to VeraCrypt can show the same issue (https://bbs.archlinux.org/viewtopic.php?pid=2288750)

The important limitation is that this explanation applies to FUSE-backed filesystems such as NTFS via ntfs-3g. A VeraCrypt volume
formatted as ext4 and mounted through the native /dev/mapper/veracryptN device should not hit the same ntfs-3g/fuseblk path.
Testing that case would be useful.

To check whether an affected mount is in this category, please run this command, replacing /media/veracrypt1 with the actual
VeraCrypt mount point:

findmnt -T /media/veracrypt1 -o SOURCE,FSTYPE,OPTIONS

If the filesystem type is fuseblk, this hypothesis is relevant.