Issues with linux file permissions when refreshing tab

I’m running into a bug with file permissions when running the server on a linux machine.
For the basic workflow: The user can upload a file and then perform some actions on it. The user can also repeat the upload or upload a different file.
Now as long as the original tab is open all of this works without any problems.

Now once a user refreshes the tab (and still has the same sessionid) and tries to upload a file with an identical filename of a file that was previously updated the server throws a “FileNotFoundException”. I checked and the file does exist, so I thought it could be some problem with file permissions. That would be weird though, because overwriting and existing file worked in the original tab.

I’ve also tried giving the file all permissions with chmod 777, but the issue persisted. Any clue what the issue could be?
The files are stored under /tmp/${sessionId}/

May I bump this? Is this a thing in discord forums?
Still having that issue that under linux a refreshed tab with the same sessions seems to have problems accessing a file.

I don’t think it is related to Vaadin and more like a tomcat thing. https://stackoverflow.com/a/59608087

I just come across the privateTmp property in my own research and it sounded a lot like it could be the issue!
I will test this out, thanks for the link.

Where would the tomcat9 service lie in the case I use the built-in tomcat server of the development environment?

I would apply those configuration to the systemd file starting your application

How would I go about it, if I don’t have a .service file for the application? In particular how would that be fixed in the embedded tomcat of the dev environment?

No idea; for me it sounded like a production / linux server problem

it’s both present on our linux server running its dedicated Tomcat9 server, and on linux dev environments running the built in tomcat server of spring

Sounds like you consult the Tomcat docs if you wanna get it working locally as well

unfortunately the fix proposed in the SO post didn’t solve the issue on our server either. There must be something more going on