FATAL: Encryption is enabled. Aborted.

[TonyNoIT]

After I tried to - sudo -u www-data php ./occ memories:index
Give error
FATAL: Encryption is enabled. Aborted.

Is this module works with standard encryption on Nextcloud?

[pulsejet]

Is this module works with standard encryption on Nextcloud?

No. Because memories does server-side processing, it cannot support end-to-end encrypted files without leaking information.

[eltos]

@pulsejet could you elaborate a bit more on this?
Nextcloud features two kinds of encryption:

• Server-side encryption: files on the drive are encrypted, but the server has the keys when a user is logged in
• End-to-end encryption: No way for the server to decrypt files

Is it only the latter or both that are not supported?
Is it just the occ command for initial indexing of existing files, or the memories app in general not supporting it?
Is there an alternative way for initial indexing (e.g. deleting and re-uploading all files)?

[eltos]

Just tested it with server-side encryption: the occ command fails, but all images uploaded after installation of the Memories app do show up in the timeline. So maybe all it needs to fully support server-side encryption is a method to do the indexing on a per-user basis, e.g. from the welcome screen when a user first opens the app?

[pulsejet]

I assumed the issue is about e2e encryption (maybe incorrectly). Not sure how the internals of server-side encryption work, but I'm willing to accept a pull request if we can support this.

[eltos]

Might be worth taking a look how the metadata app does it. Maybe there is even a way to interface with it directly.

[TonyNoIT]

That what I did for my files…
If files uploaded after - everything work 🤷‍♂️

[eltos]

Well, actually even the occ memories:index command works perfectly fine with server-side encryption. Just comment out that return statement in lib/Command/Index.php

if ($this->encryptionManager->isEnabled()) {
    error_log('FATAL: Encryption is enabled. Aborted.');
    return 1;
}

I observed that Nextcloud automatically provides a decrypted copy in /tmp, and when getExifFromFile is called the $path = $file->getStorage()->getLocalFile($file->getInternalPath()); is that temporary (unencrypted) file, so exiftool has no problem reading it.

Likewise, for the safety-check in updateExifDate: I see that you "Don't want to mess these up, definitely", but it actually just works if you are brave enough 😉

I haven't found official documentation on this unencrypted tmp-file mechanism, this is all inductive reasoning. You probably want to verify that independently. Plus, for E2E encryption, these safety checks might be wise to keep.