@ianhyzy Killed my entire dedicated server at OVH about 10 times today. Poor server techs had to go manually start it a bunch of times.
I ended up just cutting a partition and deploying a VPS on 18.04.5 and moved it all to there, which seems fine with the Cloudron updates that I installed last night, which didn't seem so fine on 20.04 x64.
Tech said that the screen was black & wouldn't respond to keyboard input, had to hard re/boot several times. But I haven't looked at any logs yet to see what was happening. So that's all I got for now.
@drpaneas Ah thanks, I think I found the bug. It seems a "permission denied" issue is being flagged incorrectly as directory does not exist. The chown you did essentially changed permissions and fixed the issue.
Note: It took me a minute to put this together while @nebulon was responding and I got pulled onto something else for a minute, but I think the detailed writeup is worth having for posterity, so I'll post it anyway.
So what's going on here is that the app in question isn't reading the "right" headers to find the remote address. Basically, the inbound requests come in and hit the box-level nginx reverse proxy, which forwards the request on with the original inbound IP in the X-Forwarded-For header. Since from the sound of it, you're just routing straight to your app in the container, you'll want to either reconfigure your logging library to use the forwarded IP header as the client IP or drop nginx or similar as a reverse proxy in front of your app and configure it to rearrange the incoming headers as your app needs.
Sounds like you can just adjust a configuration so that this (your existing flow) works nicely:
Basically, here, the headers are adjusted in the "Step 1" processing as they reach the Cloudron so when they reach your app, the proxied headers have already gone into place. Again, this configuration should be fine with the configuration that @nebulon mentioned going in, since that should reconfigure your framework to read these adjusted headers correctly.
Failing that, or for apps with more complex setup or which aren't able to read those headers on their own by configuration, the solution is to further proxy those requests, by adding nginx or similar to take over the "Step 3" handoff and smooth out any specific details (like re-adjusting headers) for the app, and having it proxy those requests down to your app, all in-container, so that the logging and such in your app will all match up with expectations/reality. The whole point of the second reverse proxy when it's added it to make the world appear as it needs to for the app and/or its components inside the container.
@girish Yes, I guess the email from my Cloudron domain is getting flagged as spam on their side, and then they reply to me without removing it from the Subject line. Ok, I'll get in touch with them and figure things out. As far as I know, I've done all I should to legitimize my cloudron domain - they use a provincial ISP for the email so I suspect they are picky.
@annaooo To add to this, it's best to create shared folders under /srv, /mnt, /opt instead of /home/yellowtent. The /home/yellowtent is the home directory of the user which cloudron platform runs as and it's not meant for user data. In fact, it won't let you create a volume under /home/yellowtent.