Yup. VeraCrypt is also portable but it would play badly with web-backed storage that uploads/downlaods whole files. Would only be usable on local NAS storage. That said, I’m curious to see how Cryptomator performs on local NAS for high-perf applications compared to VC or LUKS. E.g. if you want to have a large photo collection with Immich on top of it. 😀 Sadly I don’t have NAS anymore to test it out.
The fact you didn’t mention the barest of minimums in your comment if where the issue lies.
I described the procedure step-by-step mentioning each layer. That’s the best I could do.
OP specifically said they DID NOT want exactly what you’re describing.
OP said they’re worried about performance with this solution. Hence why my first response addressed the performance issue. The rest was responding to you (and anyone else who is reading) since you thought that is not an E2E solution. I tried explaining why it’s client-side encryption and no keys are stored on the host.
OP, test the performance of LUKS image, VeraCrypt (if entertaining that) and Cryptomator and tell us how they perform! 😁
You could run a small set of fio runs to test sequential, random and parallel perf.
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. It’s stuff that’s good to know so I’d be happy to answer questions.
E:
The procedure on the client is roughly:
cd /network/share/mountpoint
fallocate -l 1G test.img
cryptsetup luksFormat test.img
cryptsetup open test.img test_decrypted
mkfs.ext4 /dev/mapper/test_decrypted
mount /dev/mapper/test_decrypted /mnt
Once that’s done, subsequent uses are:
cryptsetup open test.img test_decrypted
mount /dev/mapper/test_decrypted /mnt
Of course that can be automated further.
Just tested it in a local dir and it works fine. The only difference between that and the real scenario is whether test.img resides on a network mount or local disk. Since the network mounts behave like normal disks, everything else works the same. The only concern is what the performance would be, which depends on how the underlying network fs handles reads/writes to test.img. E.g. if you change 0.5MB, does it send that 0.5MB or does it rewrite the whole 1GB file. When reading, does it have to read the whole 1GB file or just parts of it as needed. Etc.
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 single vol when 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.cryptomator
This 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.
Not sure I’m getting you and probably didn’t explain myself well. Here’s what I mean:
At no point does the client’s key leave their computer and the host only ever sees encrypted data.
Subsequent uses without automation:
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.
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.
Everything is relative even if we agree that some things are absolute by convention. An unchanging signal doesn’t carry much information. 😄
This is the version I setup just yesterday. Much simpler setup than the AIO. The AIO controls Docker to manage its collection of containers.
Shitty ass thin client running cheap hw that can’t do anything, a.k.a. Chromebook.
And when they do, you take care of it. Also, if you use Tailscale or equiv, you can stop Syncthing’s exposure to the internet. Then you can stay on a fixed version across clients and limit unexpected breakage that comes with autotomatic updates.
Build a Syncthing Android apk yourself. You don’t need to update to every release. I’m still using 1.30 with 2.x.
Is there difference in how much storage space is needed between the two approaches?
How does this compare to redarc? It seems to be similar.
This is going to be a bigger deal than I thought. Can’t cross 91% lib scan even if I delete the music lib and then upgrade. Even turning on debug logging doesn’t reveal anything helpful. Rolling back to 10.10 for now. Will attempt again when they force me to upgrade.
Good note.
I seem to be suffering from this issue. Lotsa spam in the logs and the scan job doesn’t seem to be moving. The next attempt would be, revert, disable music lib and upgrade. Then deal with the music lib separately. But I’ll let it run another 12-24 hours.
My god what a shit show.
It’s all normal though. Software development is hard and big changes mean more regressions. You do the changes when needed, then you work on squashing the bugs.
Library scan still going here. At least something is spinning because one CPU thread is pegged to 100%.
I do. It could be this:
After the migration it is recommended that you perform a full scan through the admin dashboard. We have observed that for some users, some elements might not work properly otherwise (e.g parental ratings). As of RC8 a scan for missing metadata may be required for music libraries to function properly. The first scan after the migration might also take quite a bit longer than usual, though subsequent scans should be as quick as before.
From the release notes.
The last messages in the log are from music lib scanning. I’m leaving it be for now.
Fucking hell. OK, I’ll upgrade again and wait longer. Mine’s ~15TB.
Thanks for reporting the results! TIL about cryfs.