With the announcement of Joplin Cloud Beta Programme in mind...
With a storage limit per item what about E2EE?
I created an account on a Joplin server (2.0.9) with an item limit, 10MB. I then created a note (Client 2.0.9) and added a 9MB file as an attachment. The new note and the attachment were synced.
I then enabled E2EE. The crypted version of the attached file was 16MB. The client was synced again but the sync failed with "Error. name is not defined".
E2EE was switched off and the client could sync again.
If what I found was the item limit kicking in, then a 10MB account may actually have to have a 18MB limit if E2EE is used. Also error messaging possibly needs a bit of a looking at so the user knows that the item limit is causing the sync problem and what item it is that has to be removed before the sync will work again. (Will "note history" be a problem when it comes to deleting a file that is too large to sync?)
Just wondering whether @james-carroll's global storage limit suggestion may make things easier to manage. "A basic account comes with xMB of server storage. Please note that if E2EE is activated your data may take up almost twice as much space as when unencrypted and so you will reach your limit much quicker." Then the client needs to be able to tell the user "Server storage capacity reached".
2 Likes
Do you have a line number for the error message? (in the server log ideally, but maybe it's also in app log). This error is a bug so not related to the storage limit, which should display a proper error message.
Also the size limit applies to the plain text item size, so even if it's over the limit once encrypted, it will still go though. 18MB for an encrypted item with a limit of 10MB should work.
The item size limit is useful to restrict the bandwidth, which is more costly than storage. And especially with E2EE, every time a note is changed it has to be uploaded entirely, so that can add up if each note or attachment is quite large. Total storage should probably be capped too, but it seems more manageable.
1 Like
Here's the Joplin client log.
log.txt (43.0 KB)
The error seems to relate to item cbddbae1f6e947259ba2e50932e2a39a which is the 16MiB encrypted file.
The file's real name is current average.rtf. It is a fake file of exactly 9MiB. It is not an RTF, just random data. I cannot attach it as it is too big for Discourse and being random data it does not compress well.
I am new to Docker so I don't yet know how to get in and retrieve logs. The "logs" section of the server (/changes) just appears to show creates, deletes and updates.
The server is ARM64 (florider's image) and the db is Postgres:latest.
For your information Joplin portable is being used in a Virtual Box Windows 10 VM with the user "vbox". Portable is being run from the desktop. References to "purple.intra" are for an internal test network which is equipped with its own CA. At the moment Joplin is ignoring self-signed errors but will work if pointed at the domain certs.
It's indeed a server error but there's not much info in the app log unfortunately. On the server, to get the log you could run docker-compose logs, which hopefully should have a full stack trace for the error. Any chance you could try that?
This is the docker-compose logs output which possibly contains everything I have tried to abuse the server over the last couple of days!
logs.txt (308.7 KB)
There was an earlier test where I tried to add several 9MiB files and Joplin just seemed to stall. If what I subsequently found may be due to a "compound effect" let me know and I will reset everything...
Thanks for the log, I see what the issue is now. The item was indeed over the limit but there was an error in the way the error message was generated, thus the non-sensical message. I'll fix this for the next release.
How did you define the limit by the way? Because it should be in bytes, so 10x1024x1024 for 10 MB.
Yes, I set it at the size you mention (10 Mebibytes).