I sync Android - Ubuntu via Nextcloud and use encryption.
In one of my notes I included a jpg, which was encrypted (same key) as well. Whatever went wrong the encrypted jpg got lost while syncing. I know the name (e5edcb5f0dcc48a49498cb00d2362a3c.md) and restored it from a backup. The reference in the editor is still there, but the link in the db is probably lost:
On the sync target, is the JPEG file that matches e5edcb5f0dcc48a49498cb00d2362a3c.md still in the .resource folder? If so, I would just add the .md file on the sync target, then sync from the device and it should pick up the file.
That was my problem: the file was in the .resource folder, was not attached to the note. Tried restarting Joplin several times.
Is there any way to decrypt from the linux shell?
e5edcb5f0dcc48a49498cb00d2362a3c.md as well as .resource/e5edcb5f0dcc48a49498cb00d2362a3c are on the sync target?
If so, the issue is that they are not being decyrpted on your computer? or not being synced?
If not being synced, how do you know that’s the case? Did you open the SQLite database to confirm?
You can use joplin e2ee decryption <path> to decrypt a file but I’m not sure if this is what you need in this case
Sorry for my late response, I did not want to seem too stupid, although I am still not wiser
I did look into the db, selected select * from notes where title like ‘%title%’; e5edcb5f0dcc48a49498cb00d2362a3c in the body, and then could not find
select * from notes where id like ‘e5edcb5f0dcc48a49498cb00d2362a3c%’;
I seem to have issues with the jopin e2ee as well:
joplin e2ee decrypt -v 007c0991648345409fce8ae3cf3a79db.md
Invalid encryption identifier. Data is not actually encrypted? ID was: 007c0
joplin e2ee status -v 007c0991648345409fce8ae3cf3a79db.md
Encryption is: Enabled
As e5edc is an image (a resource) you would need to check in the resources table:
select * from resources where id = 'e5edcb5f0dcc48a49498cb00d2362a3c';
If you want to check if this resource is used in a note, you could use this query:
select * from notes where body like '%e5edcb5f0dcc48a49498cb00d2362a3c%';
Do any of these queries bring up anything?
Next could you check in ~/.config/joplin-desktop/resources if the file e5edcb5f0dcc48a49498cb00d2362a3c.jpg is there?
I don’t quite understand your decrypt query as you mentioned one ID (e5edcb5…) but you try to decrypt another (007c09…). If it says “Data is not actually encrypted?” maybe it’s indeed not encrypted. You can verify this by opening the .md file and check the encryption_applied field. It will be “1” if the data is actually encrypted.
Thanks a lot for your effort and info!
cat 007c0991648345409fce8ae3cf3a79db.md
…
encryption_applied: 1
I understand it should be encrypted?
I blamed the nextcloud sync for loosing the encrypted jpg and had a nonencrypted version of theat jpg still and added that as a new jpg to the note. I changed my sync to “File System” and included it in my unison sync which I trust in for all my devices.
I will try to pull the old db and files from the zfs snapshot and try your the checks you recommend
Now I looked into the data from Sep 12:
The only thing in ~/.config/joplin-desktop/resources is: /e5edcb5f0dcc48a49498cb00d2362a3c.crypted
select * from resources where id = ‘e5edcb5f0dcc48a49498cb00d2362a3c’;
delivers no match
select * from resources where id = ‘e5edcb5f0dcc48a49498cb00d2362a3c’;
matches with id 5b54fdc5b9714821b8f525044f06c6f8 (I assume the note?) and a parent id (Notebook?)
and body:
the double jpg extension is because of my mistake specifying the filename converting a pdf to a jpg (the pdf seems to not be supported on Android yet)
Regarding joplin e2ee decryption <path>:
I would be really happy to be able to use that, as it would be very helpfull to track encrypted synchronized files when I am not certain how well my sync worked or I end up with files that seem to belong nowhere
I really like Joplin and use it for (to me) important stuff
I have a potentially related issue: I had a note with a few images in it. Yesterday I’ve noticed that across all of my synced devices, all but the last of the images has disappeared.
The note text is unchanged and looks like this: 
If I search my hard drive for 3669f9eaa3aa4ef589c94974a42f91f8, I can only find a 3669f9eaa3aa4ef589c94974a42f91f8.crypted file in my .config\joplin-desktop\resources folder.
How could this happen? (I am now using the PC I’ve added the pictures on, so it’s not that it just hasn’t decrypted yet. The note is weeks old and the sync process has finished several times today, so I don’t think anything’s waiting for decryption.
Should I try the joplin e2ee decryption method? (I don’t even have the terminal version of the app installed yet.)
Is there any way to find out whether other resources were affected? I haven’t discovered any other discrepancies by randomly clicking around, but am quite anxious about the possibility of losing something else.
How old is the note? For a short time there was a bug that would incorrectly delete resources of new notes so just wondering if that’s your issue.
If needed you can indeed recover the image using the e2ee command as long as you still have your master key.
It was created in the middle of September, IIRC.
Thanks, I'll try that when I get the CLI version working. (So far I only got some weird npm and permission errors. 
I'll look into it.)
Laurent, I am very sorry to pick up that thread again: I do not get the single md decryption:
I have one file in a directory:
cat 60642171cb734bde8fcd4f6dca03ed05.md
…
encryption_cipher_text: JED01000022017e41ef181afc47deb70c3d78a0f3ebab000386{
…
seems to be encrypted
e2ee status:
$ joplin e2ee -v target-status ./
Encrypted items: 1/1
Encrypted resources: 0/0
Other items (never encrypted): 0
# Encrypted paths
.//60642171cb734bde8fcd4f6dca03ed05.md
# Decrypted paths
$ joplin e2ee decrypt 60642171cb734bde8fcd4f6dca03ed05.md
Invalid encryption identifier. Data is not actually encrypted? ID was: 60642
target-status is the same.I assume I do something very basic wrong but cannot find a solution. Can you please clarify?
I know this is an old thread, but once again I'm trying to get my lost resources back.
So after trying a few things, these are my findings.
My naive attempt - to joplin export and check if the file is in the exported dir - didn't work.
My lost files are mostly .png images. They probably really are encrypted, i've tried just renaming the .crypted file to .png, but it isn't a valid file.
(Aside: there are several mentions of joplin e2ee dectpytion. Seems to me the actual command is joplin e2ee decrypt, and Joplin does not give any complaint when you put in the wrong one.)
So I've tried (under WSL):
> joplin e2ee -v decrypt /mnt/c/Users/name/.config/joplin-desktop/resources/c6f30f6834ea42a59196b40074b1f271.crypted
Invalid encryption identifier. Data is not actually encrypted? ID was: /mnt/
Not sure what the /mnt/ there means. Since it's at the beginning, I've tried adding quotes around the path, in case the string just didn't get passed as I'd expect, but it didn't help.
select * from notes where body like '%c6f30f6834ea42a59196b40074b1f271%';
returns the note the resource is referenced from.
However, this:
select * from resources where id = 'c6f30f6834ea42a59196b40074b1f271';
returns 0 rows.
Is there anything else I could try, @laurent ?
Thanks!
Ok, update:
I got one of them to decrypt, but it probably isn't a great way 
I've manually inserted a row into the resources table. I've filled in all of the columns based on the rows above them, except I set the value of the last two columns to 1 instead of 0, because they had the word 'encryption' in them, more or less. #proTechniques
When I next launched Joplin, the image actually decrypted and displayed correctly. The DB now still has 1 in the encryption_applied column, and 0 in encryption_blob_encrypted.
However, when I run
select * from resource_local_states where resource_id = 'c6f30f6834ea42a59196b40074b1f271';
there are still 0 rows there.
I'm not sure there should be one; after all, I have 632 resources, and only 564 resource_local_states.
And I have a baaaad feeling about all these edits.
So what should I do? Do more edits?
Decrypt them all like this, copy them over somewhere else, restore the DB to the original state and copy the resources there as new files? (Tried this and synced, the other one synced and displayed correctly.)
Am I at a risk of ruining my sync target somehow?
(I did make a JEX export and a joplin export dump and a copy of the sqlite DB before editing anything, so I hope I'm at least recoverable...)
Hmm, I’ve removed the command to decrypt a single file recently because it had some issues, so there’s not any clean way to do it, only hacking like you did.
I think there should be a command like fix_resources, which would go through the resource files and create a db row for those that miss one. They will then be picked up by the decryption worker and decrypted.
It should be quite easy to add this so I’ll have a look.
But also I wonder how it happened in the first place.
Thanks. That sounds like a good idea.
I went ahead and grabbed all of the .crypted files, then removed those whose IDs are in the DB... and got 133 missing resource IDs. That is a bit more than I'd expected.
If I add them en masse, decrypt and sync, do you think I'd fix them all at once without breaking anything?
If there are any that are no longer referenced, will Joplin still remove them correctly?
Oh yeah, also regarding this:
when I tried the joplin export again, it told me some of the resources are not decrypted yet and I should wait until later. When I changed the encryption_applied value to 0 manually and tried again, not only did it work, but it also actually synced to my other device correctly this time. (I removed the original resource link from the note and just kept the copy. Wouldn't want to do this manually for >130 resources, though.)
Should I do this for all of them?
Thanks!
In the latest CLI version I’ve added a command joplin e2ee decrypt-file /path/to/crypted, which might help with what you’re trying to do. Note that it’s mainly to recover resources that have lost their metadata (the .md file), and it will simply decrypt the file without adding it to the Joplin database.
Thanks! I’ve solved the issue the way I’d described above, but this will certainly be handy if it happens again.
One last question: there seem to be a lot of resources (~100) which weren’t referenced from any note, when I did the search in SQLite. My plan is to just ignore them, they don’t hurt anything. But does Joplin do any kind of clean-up on them?
There’s indeed an issue as when the resource gets deleted the crypted file currently stays there while it should be deleted too, so that would indeed need to be fixed at some point.