MX Linux Forum

This may be a ridiculous question but I'll ask anyway.

I create snapshots including everything for personal use. I put them on a Ventoy USB and can boot into last month, the month before, etc. to occasionally look for something I may have deleted or changed. My password manager, KeepassXC and TOTP is in the backup but is protected by it's own encryption and passphrase.

If I have made major changes and know that I want to keep them, I'll also make a live USB. I always choose to encrypt and use the same Luks passphrase I always use on my installed version. If I use dd the image is not bootable.

Is is possible to use command line tools in MX to make a snapshot that is already encrypted with a given passphrase? For example, the initial boot of the live USB uses a 2 word temporary passphrase. Can the tools be used to pass our own longer passphrase and create an ISO that is bootable but stops at the Luks passphrase as a live install does? I wouldn't necessarily create the USB but if I keep ISOs on a Ventoy drive and they are not encrypted I would need to physically secure these backups since they contain my passwords and more.

Any thoughts on this possibility?

Not that I am aware of, consequently I write all of my MX Snapshots to a LUKS encrypted HDD

":..Can the tools be used to pass our own longer passphrase and create an ISO..." That would seem to be a good idea ie then no need to boot the USB to changed and save to password

This is a lot like rod178 does, but a different container.

I keep my saved snapshots on a veracyrpt volume, and then if I need them then I copy out to my ventoy drive.

An Honestly Amazing Concept and idea. Charles mention to copy after creation the snapshot.iso into a vera-crypt volume is remarkably in the form of "Absolute Brilliance" is possibly your best concept to consider.

consider a copy of the vera-crypt version your installed to using, - copy that 2 places, one your system to snapshot say /opt/myApps or something like,
and off your system for the year or 17 month down the road you have to recall these images and get it back to a state you can install and recover by.

So that being "Create your Masters Copy" - consider to document your steps - don't leave out anything.

PS: programs do evolve and odd chance the newer version available at the time you "Have to Restore" is and might not be "backwards compatible"
At least you have a copy of Vera-crypt or like wise available to install and use to allow your recovery of said snapshot image.iso

Right on Charles.

Thanks, all. I do keep my snapshots on encrypted drives. Everything is encrypted.

Ventoy is convenient but since I can't encrypt the boot images I keep the Ventoy drive in a safe. I have mounted my encrypted drives to copy snapshots to Ventoy before and use them. I am used to booting to the enter passphrase screen and actually find it disconcerting when using an unencrypted snapshot on Ventoy. It's funny what people get used to...

@atomick thanks. @fan_of_LTS indeed that works and as long as the are on encrypted drive I think you have your answer.

I wonder if it's possible to do, I have to study to see what is the live system doing when it's using encryption for persistence live system -- does it encrypt/decrypt linuxfs? how does it detect the encryption... I assume it would be pretty simple to encrypt linuxfs once is created before the ISO is built (so the ISO stuff like kernel would be unencrypted but linuxfs that contains everything else would be encrypted.

Adrian wrote: Wed Jul 09, 2025 9:36 pm I assume it would be pretty simple to encrypt linuxfs once is created before the ISO is built (so the ISO stuff like kernel would be unencrypted but linuxfs that contains everything else would be encrypted.

My first thought, untested of course, was that the persistent storage partition that Ventoy provides doesn't have to be any certain kind of thing. One could mount it through encfs and store any kind of ISO or linuxfs squashfs data in it.

One could potentially patch mx-snapshot to prompt for a key and encrypt the output but then decrypting that output would be a problem; encrypting the data at creation time is less useful here than encrypting the storage container and then decrypting it when it's needed. At that point one could just as easily make a regular snapshot and use GnuPG or age or scrypt or any other kind of method to encrypt it. Boot Ventoy normally, look at the encrypted data on the persistent partition, create a ramdisk in memory, decrypt the data into the ramdisk, and unsquash it to the target machine.

Seems like a ton of work and it's super easy to screw up, but I'm sure it's doable.

I was talking about MX/antiX persistence. There's a mechanism to deal with encrypted data, I just need to know if it's possible to encrypt linuxfs and if that mechanism can see that encryption automatically and prompt for password like it does in case of persistence.

Adrian wrote: Wed Jul 09, 2025 10:57 pm I was talking about MX/antiX persistence. There's a mechanism to deal with encrypted data, I just need to know if it's possible to encrypt linuxfs and if that mechanism can see that encryption automatically and prompt for password like it does in case of persistence.

And that's great; my thinking was in terms of cold storage: keeping data encrypted at rest but still able to reference it as a real ISO from, say, Ventoy, or a USB live session running from from an ISO.

Writing the Snasphot to an encyrpted container, LUKS physical device or fscrypt folder if restricted on a laptop or such, is the easy part. I would still like to be able to automatically write the iso to the USB stick, with a password that was set in the Snapshot creation process. Also would like to permanently change the path of the Snapshot

Somewhat OT but another angle would be to step back and delegate the decrypting step(s) to Ventoy itself. This would enable storing all sorts of ISOs/WIMs/etc with confidential information on a stick. Basically Ventoy would need to recognise that some file is not bootable as-is but is an encrypted container (say a VeraCrypt file though any reliable and secure encrypted container format could be used). It would then ask for credentials, mount the container and start the ISO/WIM/etc inside the container. Easier said than done, I know, and also outside the realm of MX.

rod178 wrote: Thu Jul 10, 2025 6:16 am Writing the Snasphot to an encyrpted container, LUKS physical device or fscrypt folder if restricted on a laptop or such, is the easy part. I would still like to be able to automatically write the iso to the USB stick, with a password that was set in the Snapshot creation process. Also would like to permanently change the path of the Snapshot

the gui tool might not support it, but the command line live-usb-maker tool will let you specify the password at live-usb creation.

Thanks I'll have a look

I have also previously endeavoured to change the path in /etc/mx-snapshot.conf
In the gui the change did not stick.

That file is the primary - the one you should change is at your home directory
consider a copy before modify, in the middle is the Save too mx-snapshot_directory=/home/snapshot - this is the what you can change to your other partition directory/snapshot
I have a 2T drive split 2x 1T partitions for snapshot and vbox clones . it is also set to hidden and it is only owned by myself (perms 0700) and also has the stickky bit enabled.
it is auto mounted via the /etc/fstab and the mount point is also .hidden So in a form its safe from Web access down the throat of any browser no matter how you might feel to think you are protected in a form you are not.

one concept is to write a mount by need a script to mount up a drive set to retain your encryption protection. And umount when finished with copy transfers for saving.

Would think by your impress that you maybe doing crypto trade and want to keep everything as super safe you can.
So if you have some level of protection working on line for doing this. Anything Upstream you perform is now the magnitude of your protections schema. As Charles So Brilliantly suggest to keeping snapshots into a vera-crypt vault is most excellent.
a one step up would be make this vault only accessible to your self when your offline and disconnected or your nic both eth0 and wlan0 are offline downed or cable and wifi disconnected and turned off. "BEFORE you Enable turn up mount this Protected Vault "

That alone is going to be a safe challenge and I recommend 3x that protection as well. With 2 of those copies off out of the systems. Tape backups for Enterprise have 3 copies 2 are off site as backup to the backup.
As well now you have wicked hard long Passwd Keys / wallets to contend with and their encryption worries for what say happen 18 months from now.

Think this thru when you complete a method "Test IT" if your familiar with VirtualBox continue with and clone your snapshot to guest in Vbox and test your theory practical.
And Document everything for that practical purpose your mind is in sync with your hands and brain is operation for handling it all. And then some. Think of the inevitable and its circumstances can save you that duration when you might be tested for this. and your self.

Food for thought.

PS: consider to try but think the purpose use for snapshot is best suited for its purpose - optn 2 "Resetting Accounts" here you can when deploy to another workstation or device or VBox Guest to proof test the image containment.
there is where you can retain the HD Full encryption and even change it but this can get real testy on grey matter down the road.

Flash copy and find to be devious on how you hide such in your house or bury it in a jar in your back yard with the dog.

Tree holes are no longer a good hide place. This topic alone could real chapters of imagination and things to do try and suggest let alone be overwhelming to detail.
consider all concept even write pro / con down a page and run thru this. Sounds really silly believe me in 2yrs from now this is all going to be mush unless you practice a something method procedures. It will make sense 2 yrs from now.

Logical Thought Process. Cheers.

/home/rod/.config/MX-Linux/mx-snapshot.conf did the trick

PS imo VeraCrypt is only applicable if you are not using ext4, require cross platform compatibility and plausible deniability . In all other cases fscrypt is the better option

For physical devices LUKS is the better option

There is no need to hide devices if using strong passwords, especially with LUKS. I actually carry all of my encrypted files in my keycase on a micro usb drive, in case the house burns down
My Desktop MX drive and Data Drives are LUKS encrypted
Several Laptops, accessible by multiple users, contain fscrypt encrypted directories, accessible to individual users via passwords

Use VeraCrypt if:
-You need cross-platform compatibility (e.g., sharing encrypted containers with Windows or macOS).
-Plausible deniability is important (e.g., hidden volumes for sensitive data).
-You prefer a GUI or need to encrypt portable drives or specific container files.
- you are not using ext4
--Example: Encrypt a USB drive for use across Linux and Windows systems.

Use fscrypt if:
-You only need to encrypt specific directories or files (e.g., /home/user/documents ).
-You prioritize performance and want minimal overhead on ext4 filesystems.
-Metadata leakage is not a concern for your threat model.
--Example: Encrypt a user’s home directory on a multi-user MX Linux system.

Use LUKS if:
-You need full-disk encryption or want to encrypt entire partitions.
-You prioritize native integration and performance on MX Linux.
-Cross-platform support is not required, and you want a mature, Linux-centric solution.
--Example: Encrypt the entire system drive for a single-user laptop.

Given the usb maker command line version, it seems the only thing missing is the ability to have it output an ISO instead of requiring the physical drive. I hadn't noticed the option to provide the passphrase as a file. I usually just booted my flash drives and retyped the same passprhrase I usually use for external media.

I later ran
Unlike running from the gui, it used


ie instead of To create the password protected LiveUSB Can customize the live USB further with options like:
--percent=XX: Set the percentage of the USB drive to use (e.g., --percent=50 for 50% of the drive).
--label=NAME: Set a custom label for the filesystem (e.g., --label=MXLiveUSB).
--persist: Enable persistence to save changes across reboots (e.g., --persist=home for home directory persistence).

When I have some spare time I'll have a crack at running through a dialogue using Yad.