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).

    • Avid Amoeba@lemmy.caEnglish
      2·
      1 hour ago

      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.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.

  • Decronym@lemmy.decronym.xyzBEnglish
    3·
    1 hour ago

    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

    3 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]

  • irmadlad@lemmy.worldEnglish
    3·
    2 hours ago

    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.

  • Avid Amoeba@lemmy.caEnglish
    2·
    1 hour ago

    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.

    • just_another_person@lemmy.worldEnglish
      22·
      2 hours ago

      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.

      • Avid Amoeba@lemmy.caEnglish
        21·
        2 hours ago

        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.

  • just_another_person@lemmy.worldEnglish
    11·
    3 hours ago

    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.