(Bug report) Trilium doesn't really remove attachments

[miltuss]

Trilium Version

0.63.5

What operating system are you using?

Other Linux

What is your setup?

Server access only

Operating System Version

22.10

Description

I'm having a big problem with trilium. I did a test and noticed that it doesn't really remove attachments!

I had an 800MB database, I added a 200MB video to one note and an image to another note. Which expanded the database to 1GB. Then I deleted the two attachments of the two notes, which did not reduce the size of the database!

I found the image in the revisions of the note, I opened it in a separate link from the web browser, and I deleted all the revision versions of the note, which should have completely deleted this image , but it was still there via the URL I opened before, so it still hasn't been deleted.

The video is not present in the review of the note and has been removed from the attachments, yet the database still weighs 1GB, which means that the video has not been deleted either!

I clicked on the Erase deleted notes now and Erase unused attachment notes now buttons, then I restarted the server, but the database still weighs 1GB and the image is still stored in the database despite having removed it in the revisions in the note and in the attachments. Same for the 200MB video which was not deleted.

Why does Trilium not delete attachments?

How to force the deletion of these files which are normally supposed to already be deleted?

Error logs

No response

[Nriver]

Options - advance - vacuum database

[miltuss]

Options - advance - vacuum database

THANKS. Can you tell me how to disable the 250MB file storage limit?

[dosubot[bot]]

You can disable the 250MB file storage limit in Trilium by starting the server with the environment variable TRILIUM_NO_UPLOAD_LIMIT=1. For example, run:

TRILIUM_NO_UPLOAD_LIMIT=1 node src/www

or however you normally launch Trilium on your server. This removes the artificial limit, but be aware that Trilium is not designed for large file storage—files over 524MB may cause crashes or instability due to memory and sync constraints, since uploads are handled in a single chunk in memory and not streamed or chunked. Use this with caution, and avoid very large files if possible. More details from the maintainer are available here.

If you use a reverse proxy (like nginx), make sure its upload size limit (e.g., client_max_body_size) is also set high enough or disabled, otherwise uploads may still be blocked at the proxy level.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}