Temporary files not removed
Hello,
I am having serious problem with free space in my server because of the binary temporary directory. When I check the directories' size, the /binaries/tmp folder has the 90% of the disk space. Please, note that I am not talking about the nuxeo.tmp.dir. I am talking about the tmp folder that nuxeo creates inside de directory specified in repository.binary.store property.
The problem is that, when I see / download a document, the binary of that document is copied into de tmp directory, but then, it is not removed. So that binary stays there for a long time, and in a few hours, the disk is full. Why is this happening? I think temporary files should be removed almost instantly after seeing them.
This is also a big security problem, as I use binary encription, and the files stored in the temporary directory are not encrpyted! If they are removed instantly after getting the document, then there isn't any problem, but if they stay there, it will be a big security problem.
I don't know if I am missing any configuration for tmp files. I would appreciate any help about this.
Thank you.
Hi Rodri,
Just wondering, if you can answer these questions to get a better understanding.
Have you done any encryption setup on the configuration file yet?
Which version of nuxeo is this?
When you say “Download a document”, I am assuming a document of type “File” and downloading it's binary attachment under “Main File” correct?
So if it's creating a temporary file in the /binaries/tmp directory, this is done when a binary is being used according to this quote:
While the files are in use by the application, a temporary file in clear is created. It is removed as soon as possible.
https://doc.nuxeo.com/nxdoc/file-storage/
If encryption was setup, it should create an encrypted file on the tmp directory (which it does not as you reported). Once they are done being used, they should be cleared the temporary files.
If you haven't done any encryption setup, I would suggest taking a look at this and test out the settings for nuxeo.conf
https://doc.nuxeo.com/nxdoc/implementing-encryption/
NOTE: I have limited experience with encryption myself, so I've yet to run into this issue. I tried to see if I could reproduce the issue on my local test instance, but it didn't reproduce.
 |
Peter Tucker
Developer, Granite Horizon (790) 2 4 5 |
06/20/2019 ( History) |
Here the answers to you questions: 1) Have you done any encryption setup on the configuration file yet? Yes. I have set up encryption in nuxeo.conf, and binaries are correctly encrypted in the FileSystem (I've checked that). 2) Which version of nuxeo is this? 9.1 3) When you say “Download a document”, I am assuming a document of type “File” and downloading it's binary attachment under “Main File” correct? Yes, I mean, for example, when you see it in the WebUI, or when you make a "view document" request from REST API.
You have said: "While the files are in use by the application, a temporary file in clear is created." So, in tmp directory, files are stored in clear even if binary encryption is enabled!
Anyway, one of the main problems is that the sentence "It is removed as soon as possible" is not good for me. If I am checking big files (let's say, around 1Gb files), the tmp folder is full in a matter of minutes. For example:
- I download a document in of 1Gb using REST API.
- The binary file is put into /tmp folder in clear (security problem for me).
- The download finish, so I have the binary in clear in my computer.
At this time, the binary in clear stored in /tmp folder should be removed. But it is still there! And this generates two problems: 1) Space problem in disk. 2) Security problem, as the file is in clear.
"Yes. I have set up encryption in nuxeo.conf, and binaries are correctly encrypted in the FileSystem (I've checked that)"
For clarification, the encrypted binaries you mentioned are the ones located at this directory, correct? /NUXEO_HOME/nxserver/data/binaries/data
These binaries are actually named and ordered based on their binary digest, according to this:
https://www.nuxeo.com/blog/qa-friday-binaries-stored-nuxeo/
This is the default behavior from DefaultBinaryManager, and not from setup for binary encryption. However if it's encrypted differently, then please disregard this.
From what it sounds like, it seems like it might be an issue with encryption setup on the nuxeo.conf file. Did you follow the nuxeo documentation's example for setting up encryption (I had a link for it in my previous post)?
So for the first bullet point with downloading a document with REST API, are you doing it in this format? If not, what is the format? http://my.server.com:8080/nuxeo/nxbigfile/default/b54c8b41-86c9-4c9b-bfe0-e6b1ca01313f/files:files/1/file/NUXEO_User%20stories.pdf
This is from this page: https://www.nuxeo.com/blog/qa-friday-download-files-attached-documents-rest-api/
I'm still working on trying to replicate this issue, but no luck so far. But yes, with temporary files, they should not be piling on like that to cause space and security issues. Maybe need to do a different route with encryption. Take a look here:
https://doc.nuxeo.com/nxdoc/sensitive-configuration-data-encryption/
I apologize if my answers are vague, but these are the best leads I have at the moment, unless someone else who has run into this can chime in.
nuxeo.core.binarymanager=org.nuxeo.ecm.core.blob.binary.AESBinaryManager nuxeo.core.binarymanager_key=password=my_password
And yes, I also know how binaries are stored in the FileSystem (by using MD5 and digest). So the problem is not encryption. Anyway, the main problem I want to solve in this question is why binaries are not removed from /binaries/tmp folder when they are not used. When I use them (getting the file using Java Client API for example) it's ok that the binary is copied in tmp folder, but inmediatly after the response has been sent to me, why isn't it removed?
So, to summarize, the problem is, forgetting about encryption, that files in /binaries/tmp are never removed, so the disk is full as soon as I work with big files.
Thank you for your help.