I’d like to give my users some private network storage (private from me, ie. something encrypted at rest with keys that root cannot obtain).
Do you have any recommendations?
Ideally, it should be something where files are only decrypted on the client, but server-side decryption would be acceptable too as long as the server doesn’t save the decryption keys to disk.
Before someone suggests that, I know I could just put lucks-encrypted disk images on the NAS, but I’d like the whole thing to have decent performance (the idea is to allow people to store their photos/videos, so some may have several GB of files).
You must log in or register to comment.
Share a drive with each user via SMB and tell them to use Cryptomator
Cryptomator encrypts files individually right?
E:
For the curious like me, here’s how Cryptomator makes a directory with multiple encrypted files appear as a vol with decrypted. From mount:
fuse-nio-adapter on $HOME/.local/share/Cryptomator/mnt/test type fuse.fuse-nio-adapter (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)It uses its own fuse module to present it as a volume. The real directory has its own file structure:
~/test/test$ find . ./c ./vault.cryptomator ./vault.cryptomator.12A05032.bkup ./d ./d/LO ./d/LO/AYYSWMZO35ASQ2HOACU3I7LRVIAMH4 ./d/LO/AYYSWMZO35ASQ2HOACU3I7LRVIAMH4/PmAyroZAF5W7kGoHxr3Fhi-NeQIeO7SZcufE.c9r ./d/LO/AYYSWMZO35ASQ2HOACU3I7LRVIAMH4/dirid.c9r ./IMPORTANT.rtf ./masterkey.cryptomator.7DB56291.bkup ./masterkey.cryptomatorThis looks like a good option. Perhaps more flexible than using LUKS/VeraCrypt file, but those should work too if the underlying dir is on NFS/SAMBA.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
Fewer Letters More Letters NAS Network-Attached Storage NFS Network File System, a Unix-based file-sharing protocol known for performance and efficiency SMB Server Message Block protocol for file and printer sharing; Windows-native SSH Secure Shell for remote terminal access
4 acronyms in this thread; the most compressed thread commented on today has 8 acronyms.
[Thread #1015 for this comm, first seen 23rd Jan 2026, 17:25] [FAQ] [Full list] [Contact] [Source code]
The first thing that pops into my paranoid brain is: How well do you trust these ‘users’? Personally, I would have to implicitly trust someone to be able to allow them even a few kb on my server.
Resilio sync, using encrypted shares
LUKS-encrypted images won’t have bad performance. Could also use VeraCrypt or something like that for better portability if you need cross-platform function. Expose the folders where the images are stored via NFS/SAMBA. Flexible and portable solution.
You could expose volumes with iSCSI and format/mount them on the clients. Probably don’t want to do that.
E:
LUKS-encrypted images won’t have bad performance.
Actually it depends whether the underlying network fs can do partial writes. I imagine both NFS and SAMBA can. If the file has to be fully rewritten with every change, then perf would be dead.
Those aren’t end-to-end encrypted from the user, and would need to be mounted on the local system with a key that is unique to each user. Not exactly user-friendly if supporting multiple users.
There are plenty of other solutions meant for the purpose OP is asking about.
Not sure I’m getting you and probably didn’t explain myself well. Here’s what I mean:
- Host exposes a network share (1-time setup)
- Client mounts the network share (N-time setup, could be automated)
- Client creates a LUKS or VeraCrypt (or something else) file in that network share, secured with their key. The key is generated on the client and it doesn’t leave the client or enter the host. (1-time setup)
- Client decrypts the image with their key and mounts it on the client (N-time setup, can be automated)
- Client modifies data in the decrypted vol
- Client unmounts the volume (N-time, not required)
- Client unmounts the network share (N-time, not required)
At no point does the client’s key leave their computer and the host only ever sees encrypted data.
Subsequent uses without automation:
- Client mounts network share
- Client decrypts volume
That’s at least how I understood OP’s suggestion for putting LUKS images on the NAS and that is secure indeed. They’re worried about performance.
OP said they DON’T want LUKS. I’m also missing how the admin of the server (OP) wouldn’t have or store the keys unless and have these mounts available at all times?
You seem to be suggesting there is some way for a remote user to mount a LUKS image on its host, which is not a thing unless you’re first SSH’ing to said host and mounting it and making it available for export mount elsewhere, which is clearly not what OP is asking for here when they just want space for people to store media. Maybe I’m misunderstanding.
There Hook, Filen, Yeetfile, BatchIT…tons of these self-hosted stacks that do this with auth and user management built in. That’s what OP is asking about.
The host mounts no LUKS. The host just exports a network share via NFS. The client mounts that NFS share to a local mount pount. Then the client has a dir which actually resides on the host. So far completely standard NAS stuff. Then the client creates a file in that dir. E.g. secretcontainer.img. This file is then encrypted on the client using cryptsetup (LUKS). Then it’s mounted on the client using LUKS. All the LUKS stuff happens on the client. The only interaction with the host is throgh NFS. The host just sees a file appear called secretcontainer.img on its storage. The same idea would work with VeraCrypt instead of LUKS. Or Cryptomator. Or anything else that can store encrypted data in file(s) in a directory.
LUKS can be used on a single file where the file acts as a disk device.
Also what I’m describing here is bog-standard Linux functionality that’s existed at least for 2 decades. Nothing fancy.
There’s dozens out there, but the bigger question is: what’s your current hosting setup? What NAS are you running?
It would be simpler to just run something that your NAS platform supports already or has a mobile app for. Pretty much every solution you’ll find with e2e encryption is going to have its own client.
