-
Notifications
You must be signed in to change notification settings - Fork 9.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Return 500 instead of 400 when temp directory isn't writeable #44765
Comments
@M1keF Can you work around this issue by setting the TMPDIR environment variable to a directory the application has write access to? Maybe it could match ASPNETCORE_TEMP. This is a regression, so we can look at backporting a fix that doesn't write to TMPDIR, but that is probably going to require using private reflection to call unix file mode APIs @eerhardt. On the other hand, it does seem a bit unusual to be unable to write to TMPDIR. It feels like that could break a lot of things. And it seems like the workaround should be fairly straightforward. |
I would like to introduce a temp file abstract that we write to that is controllable via DI that we use for these subsystems. |
Thanks - I can confirm that the workaround works. For my use case, it leads me to question whether it would be better to just set TMPDIR to cover all eventualities and not use ASPNETCORE_TEMP. Something I discovered whilst testing this out is that the response returned to the client is leaking out the location of the temp folder if it doesn't exist - is there a setting to prevent this detail being returned? I would also expect a 500 Internal Server error in this case rather than a 400 Bad Request. I can raise this as a separate issue if appropriate.
Thanks for your help. |
Having the temp directory location being configurable is tracked by an existing issue: #9466 Responding with a 400 instead of a 500 when the directory isn't set up correctly seems weird for sure. We're not sure how complex that would be to fix though. @blowdart What is our guidance on having ProblemDetails enabled in production? In this case, that happens to reveal the temp path. |
@brunolins16 points out that fixing this to be a 500 will prevent the exception from being exposed. 😄 |
Retitled this issue to track that ^ |
@blowdart What is our guidance on having ProblemDetails enabled in production? As it's been for 20+ years. Don't do that. If you are returning details somehow in prod by default that needs to change. |
We are experiencing the same issue with your docker image. Please provide assistance |
I don't know if I should create a separate ticket for it, but as an addition: If there is not enough disk space to read the form data (e.g., huge file upload), also a 400 is returned (incl. the not-enough-diskspace information!) instead of a plain 500. Best regards, |
I have an API created on .net core 6 and it is deployed on the Google cloud Kubernetes container. API is wrapped under Apigee API gateway. { Request: Please suggest a fix for it. |
@tarunkumarrajak: Yep, this should also result in a 500. If it's bigger than 64KB ASP.NET Core tries to stream it to the disk which fails in your case as you have a read-only file system. |
@drauch Could you suggest any resolution for this or any workaround? |
@tarunkumarrajak: As mentioned above, the workaround is to set the TMPDIR to a writable location. So you will need to add the following config to your Kubernetes Deployment YAML:
|
Note the 400 vs 500 is an aesthetic issue, the real problem is that the disk isn't writable and that requires changes to your deployment environment. E.g. we can't make this problem go away for you, but we can more clearly indicate what the problem is. |
I don't think that this is an aesthetic issue for two big reasons:
So it's a real issue for us, and we hope you can at least provide a workaround if you're not backporting a fix. Best regards, |
Thanks for your help. @M1keF It worked |
Do we document this for k8s? cc @richlander |
@M1keF Will this workaround save files in the folder "/mnt/tmp" folder? If Yes, Do we need to clean it up, once the upload job is done? |
@tarunkumarrajak Yes, all files that would normally get written to the tmp folder on the root file system will now be written to /mnt/tmp instead. Just do the same clean-up that you would normally do - the actual location of the tmp folder should be transparent to your app. When your Kubernetes container is restarted, the old /mnt/tmp folder will be deleted and a new empty one created. |
You don't need to cleanup after the upload. The file is delete on close and will be removed at the end of the upload by the framework. |
I'm writing a bunch of k8s samples. I can add one for this. Describing all the patterns that require mounts (and how to do it correctly) would be very helpful. Are we going to write this topic up as guidance somewhere (more than a bug report)? |
I think it's the bare minimum we should do here. We can also describe workarounds (like doing it all in memory and paying that cost). |
Huge thanks for this issue. After having the same 'pain' to find out that at a certain size files are written to the file system instead of keeping it in memory, I was directly searching for I do would like to see the same expected results as @M1keF . Would expect |
What's the story with this in .NET 8 if containerizing with dotnet publish? |
We were setting the path for ASPNETCORE_TEMP in the K8s environment and still facing this issue and the dotnet version we are using is dotnet 8. Is the expectation that we need to set the write permission path for TMPDIR ? |
Is there an existing issue for this?
Describe the bug
I have just upgraded my Web App from 6.0.9 to 6.0.10 and am now getting a 400 Bad Request response when making large requests to my API. My web app is hosted on a Kubernetes container using Linux with a read-only root file system with the ASPNETCORE_TEMP environment variable to be a separate file system which is writable. If I make the root file system on the container writable then the problem does not occur.
The problem occurs when making requests which exceed 64KB and results in response below being returned to the client.
On investigating the issue, I suspected that the problem was to do with large requests being written out to the file system and having looked into the code changes for 6.0.10 I suspect that the changes made in Use Path.GetTempFileName() for 600 Unix file mode' could be the cause.
Some of the changes have introduced calls to Path.GetTemplFileName() which creates a temporary file in the temp folder of the root file system, and if the root file system is read-only then this will be a problem. For example, the method below retrieves the temp folder location, taking into account ASPNETCORE_TEMP, but then in the case of a non-Windows platform then calls Path.GetTemplFileName() which will use the root file system.
aspnetcore/src/Http/WebUtilities/src/FileBufferingWriteStream.cs
Expected Behavior
I expect that by setting the temporary folder location via the ASPNETCORE_TEMP environment variable that all temporary files will be written to this folder, and so avoiding any errors caused by attempting to write to a read-only root file system.
Steps To Reproduce
Hopefully the code example I have shared is enough to go on to fix this.
Exceptions (if any)
I have not been able to locate any exceptions being raised for this problem - the only clue as to what the problem is is the message returned in the response 'Failed to read the request form. Read-only file system'. Maybe because the problem occurs when trying to access the form data the error is treated as being a problem with the form data supplied by the client and so the exception is caught and sent back to the client as a '400 Bad Request'.
.NET Version
6.0.402
Anything else?
ASP.NET Core 6.0.10
Azure Kubernetes 1.23.12
The text was updated successfully, but these errors were encountered: