Hi all,
I’m easing into Qubes at the moment while also putting together some guides for newcomers. One area that seems especially tricky is file and data management. So:
Question. What file/data management strategies have you tried in Qubes? What worked, what didn’t, and what have you ultimately settled on?
I kindly ask we steer clear of privacy/security nihilism (“no one will bother”, “the systems are already breached” etc.). Let’s just do our best and try to be constructive and welcoming. 
Some thoughts and ideas I’ve been exploring:
Files qube
A dedicated, minimal AppVM called Files seems like a good option. Since securely deleting files is important, I’m considering storing its home directory on an HDD rather than an SSD.
Note that HDDs generally overwrite data more reliably, while many consumer SSDs retain it for a lot longer than you might expect. I’m also thinking about building habits around using scrub (or similar) instead of rm.
Plausible deniability
Depending on jurisdiction and threat model, some users may want plausible deniability. Tools like VeraCrypt and Shufflecake provide it, though they can be overkill.
I’m personally interested in something lighter:
- Exposes filenames/structure/xattrs but encrypts the file contents
- Supports multiple passwords
- Automatically creates and fake-edits decoy files
Haven’t found an out-of-the-box solution yet, but it seems doable. This would also work better with remote backups than hidden-volume approaches.
Appropriate text editor
I’d like a basic editor in my Files qube. nano feels a bit dated, doesn’t sanitize Unicode, and doesn’t natively integrate with encryption. Ideally, I’d want something:
- Minimal and auditable
- Unicode-safe and auto-sanitizing
- Able to clear memory reliably
- Encryption-aware
I haven’t found one yet—curious what others use here.
Types of files in a Files qube
(a) User-created files
(b) Downloads from the web
(c) System logs from disposables (e.g., after an attack)
(d) Emails and attachments
Copying files
For (a) and (b), manual use of qvm-copy can be fine. Rudd-O’s qubes-shared-folders is another option. Either way, you need a secure, sensible workflow.
Example (only using standard Qubes tools):
disp → Files
- In a disposable: script loads plaintext into RAM, encrypts with a one-time key, copies that key to the clipboard, and sends the ciphertext to Files.
- In Files: script pastes key from clipboard, decrypts in RAM, then re-encrypts using the appropriate long-term password and saves.
Files → disp
- In Files: load ciphertext into RAM, decrypt with your password, re-encrypt with a one-time key, send to disposable.
- In disposable: script decrypts in RAM and stores to a RAM-backed filesystem.
This keeps plaintext off the disk (even if Xen/Qubes writes intermediate data), and avoids typing main passwords into anything but Files.
Email is tricky—single point of failure, complex client stacks, provider risks.
- ProtonMail: E2EE but provider can push a malicious update.
- Standards-based clients: Lose E2EE but keep compatibility.
My storage idea:
- Internet-connected qube for send/receive (never actually read mail here).
- That qube transfers mail to Files, where a script sanitizes and refuses anything with serious Unicode issues.
- View sanitized mail in a text editor, integrate with your Files workflow.
Integrating this into a plausible deniability scheme is easy—until it’s not. For example, if you store a public email using a high-security password, you may unintentionally hint at that password’s existence.
Bidirectional covert communication via email is possible, but both sides must agree on a scheme without revealing that the scheme is being used—tricky. Some users may also struggle with the concept of layering plausible deniability, which is a UX issue worth noting.
Unwanted Data Persistence
- SSDs are poor at secure erasure.
- Disposables may still leave data on disk after shutdown due to Qubes internals.
- Understanding these behaviors is key to designing mitigations.
Remote backups
I know this is controversial, but for me risk of data loss > risk of data exposure.
Idea:
- Channel from Files → internet-enabled qube (Files-Online).
- Files-Online sends encrypted/plausibly deniable data to Server 1.
- Server 1 keeps current state and periodically sends diffs to Server 2, which stores exponentially spaced backups and refuses destructive requests from Server 1.
This setup improves ransomware resistance and disaster recovery. Optionally, you can make the Files → Files-Online → Server 1 channel bidirectional to support syncing across multiple devices.
Over to you:
What’s your current approach? What’s worked well (or not) for you?