Encrypted folder unlocked but files unreadable via Samba (unrecoverable error) — ZimaOS 1.7.0

Insight & Feedback
,
1

Description
I created an encrypted folder with read/write access granted to both the admin user and the guest user. I shared this folder via Samba. Both from a Windows PC and from an Android phone, I can browse the shared folder and see the file list without any issue. However, when I try to open/read any file inside it, I get an unrecoverable error. This makes the encryption feature effectively unusable for shared access, since the content is encrypted but simply unreadable by users, defeating the purpose of the feature.

Steps to Reproduce

  1. Create an encrypted folder on ZimaOS

  2. Grant read/write permissions to both the admin user and a guest user

  3. Unlock the encrypted folder with the password

  4. Share the folder via Samba

  5. From a Windows PC: connect to the share, browse the folder (file list is visible), try to open any file

  6. From an Android phone: connect to the same share, browse the folder (file list is visible), try to open any file

Expected vs Actual Behavior

  • Expected: Once the folder is unlocked, files should open normally like any regular shared folder.

  • Actual:

  • On Windows: opening any file returns “The file does not exist or is not accessible” (translated from Italian: “il file non esiste o non è accessibile”)

  • On Android: opening a text/document file returns “File not found”; opening a video file returns “Playback error”

Before It Happened
No specific prior action — this is a fresh encrypted folder created for testing this exact workflow (encrypted folder + Samba share + guest access).

Troubleshooting Tried

  • Confirmed the folder is unlocked (green open padlock icon) at the time of testing

  • Confirmed the file list itself IS visible and browsable via Samba from both clients — only opening/reading the actual file content fails

  • Confirmed guest access works correctly for regular (non-encrypted) shared folders on the same system

System Details

  • Hardware: ZimaBoard 2, 8GB RAM

  • ZimaOS version: 1.7.0

  • Client OS tested: Windows 11, Android

  • Access method: SMB/Samba share

Question
Before filing this as a bug: is this a known limitation, or is anyone else able to successfully read files inside an encrypted folder shared via Samba? If the encrypted content is fundamentally unreadable over SMB even when unlocked, that would mean the “unlock and share” use case (unlock the folder so LAN users can access it, lock it to hide it again) is not actually functional as intended.

2

Thanks for the detailed feedback and testing!

This behavior is actually by design for security reasons. Currently, we don’t support decrypting or unlocking encrypted folders directly from Windows over SMB.

If you need to access the encrypted content, you can unlock/decrypt the folder from ZimaOS using the encryption key, including by dragging the key file into the unlock interface. Once decrypted, the files can be accessed normally.

Please make sure to keep the key file stored securely, as anyone with access to it may be able to unlock the encrypted data.

We understand the “unlock and share over LAN” workflow you described, though, and your feedback is very helpful for us in evaluating how encrypted folders should work with SMB in the future.

3

Maybe it’s because English isn’t my native language, but I’ve read your reply several times and it doesn’t feel genuine nor convincing to me.

If I understood correctly, you’re saying that the contents of an encrypted folder:

  1. can only be accessed through the ZimaOS web GUI, and

  2. cannot be accessed in Windows via Samba.

With reference to point 1), I find that such a limitation makes the app‑level encryption feature extremely restricted. It’s useful for viewing, for example, some simple text document, or video, or image, but it makes it impossible to even open a saved web page in the form of an HTML file plus its accompanying resource folder. See screenshot (the file names are indicative).

image
image1137×662 44.1 KB

With reference to point 2), after creating an encrypted folder its sharing via Samba should not be enabled, as instead happens:

image
image244×319 5.82 KB
{

image
image644×544 35.8 KB

So, please don’t write

We understand the ‘unlock and share over LAN’ workflow you described

because this “unlock and share over LAN” is not only the most natural function a user like me would expect, but it is precisely the one suggested by the ZimaOS menu entries.

Moreover, you write that

Currently, we don’t support decrypting or unlocking encrypted folders directly from Windows over SMB

which is not entirely true. This is because ZimaOS encryption, which covers both file names and their contents, is partially transparent to the user in Windows after sharing the folder, at least as far as the file names are concerned, which are therefore decrypted on the fly. This is what appears in Windows File Explorer with the encrypted folder mounted:

image
image634×259 12.6 KB

and this is what appears when the encrypted folder is unmounted:

image
image639×190 7.3 KB

The name of these files, including confidential ones, is exposed to everyone on the LAN via Samba. However, when you try to open them, each of them appears as “non‑existent.” It is very, very hard to believe that this behaviour was implemented “by design” as if Samba sharing of an encrypted folder were not intended.

Forgive the malicious thought, but to me it seems that the encryption feature in ZimaOS has been introduced in such a deficient state that it ends up being almost entirely useless, only to claim a “plus” feature in the operating system.

To conclude: I hope that the next imminent version of ZimaOS (because I would rather not wait until the Greek calends) correctly implements Samba sharing for encrypted folders, or alternatively introduces support for the LUKS filesystem or for gocryptfs. I have a $50 router that already does these things (on a single drive, I admit), and I did not expect to buy a Zimaboard and end up worse off.

Thank you for your attention.