Is there an auto-dismount in veracrypt or should I always unmount veracrypt volumes manually before shutting down to prevent a broken filesystem/container?

I found the answer for Windows in the veracrypt FAQ, but not for Linux / Ubuntu.


Here is an update, which should be the right answer!

I learned in the veracrypt forums that the option to control dismounting upon shutdown and/or suspend was introduced in version 1.19. There is no need to create the init.d scripts described above.

You can see this for yourself. I use the Ubuntu ppa provided a veracrypt package, in which there is a file called /etc/default/veracrypt in which the following setings are included:

# If enabled, the following option calls 'veracrypt -d' at shutdown. Although
# all filesystems are unmounted automatically at shutdown, only calling
# 'veracrypt -d' will stop the VeraCrypt processes and remove any device mappings.
# It probably isn't necessary to do this, but it shouldn't hurt.


# If enabled, the following option calls 'veracrypt -d' during suspend and hibernate.

In case you want to try, here's the ppa file:

deb http://ppa.launchpad.net/unit193/encryption/ubuntu cosmic main
deb-src http://ppa.launchpad.net/unit193/encryption/ubuntu cosmic main

and the version as of 2018-12-26, veracrypt-1.23.0vanirl~18.10.

|improve this answer|||||

There are so-called run levels and script are executed when a new run level is entered. On Ubuntu, these are stored in /etc/rc<run level>.d. Run level 0 is shutdown and run level 6 is reboot. So you want your script to be in /etc/rc0.d and in /etc/rc6.d.

Create the file /etc/init.d/unmount-veracrypt-volumes.sh and make this its content:

veracrypt -d -f
sleep 3

Then execute these commands:

sudo chown root /etc/init.d/unmount-veracrypt-volumes.sh
sudo chmod 751 /etc/init.d/unmount-veracrypt-volumes.sh
sudo ln -s /etc/init.d/unmount-veracrypt-volumes.sh /etc/rc0.d/K00-unmount-veracrypt-volumes.sh
sudo ln -s /etc/init.d/unmount-veracrypt-volumes.sh /etc/rc6.d/K00-unmount-veracrypt-volumes.sh

I chose K00 so the script is executed as the very first one when one of the run levels is entered. Those scripts are executed in increasing ASCII order, so the smaller the number of the symlink's name, the earlier a script is executed.

|improve this answer|||||
  • 3
    You have not clarified if this is necessary - does veracrypt not do this automatically ? – Tim Jun 4 '17 at 5:47
  • @Tim Oh, I didn't read the question very precisely. I'm sorry. I don't know that. – UTF-8 Jun 4 '17 at 13:35
  • I realize that my answer doesn't provide an answer to the question asked but I feel like deleting it would harm people who come here to learn how to implement automatic dismounting after they decided they want to do it. – UTF-8 Jun 5 '17 at 0:48
  • 1
    of course, leave it – Tim Jun 5 '17 at 8:47
  • Suggesting this instead of a systemd unit in 2017 is ... questionable. – 0xC0000022L Sep 10 '18 at 19:42

As of March 2017, a user going by the name of Bob indicates that volumes are not automatically unmounted. It is probably a good idea to take UTF-8's advice and create the run level/init script.

|improve this answer|||||
  • I noticed a bad side effect from doing this. If I suspend, the storage is unmounted. I didn't want that. I never saw trouble in 5 years of using Truecrypt/Veracrypt without formally unmounting, I'll probably go back to that. – pauljohn32 Dec 22 '18 at 20:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.