I also had similar issues as soon as I migrated to Cloudron 9.x and after a while or maybe after successful login attempts with an alternative auth flow, I had no longer any issues authenticating through OpenID. weird indeed but I have noticed similar complains about Cloudron 9 and OIDC in other threads.

Hello @nexus-ai-solutions and welcome to the Cloudron Forum It seems this is similar to https://forum.cloudron.io/topic/12500/after-update-8-0-5-all-services-wont-run-and-apps-wont-run-too-it-happen-7am-this-morning Can you please check that? If you run the following command manually: docker network rm -f cloudron what is the output?

--troubleshoot gave everything as "ok" however: root@my ~ # cloudron-support --check-db-migration /usr/bin/cloudron-support: unrecognized option '--check-db-migration' Running the start.sh fixed the backups page issue, and now the updates appear to be running (and the error is gone) thankyou!

@ghosted @mdc773 9.0.13 has the fix .

This is fixed in 9.0.13 .

@ghosted said in Update 9.0.11 Broke Services: It was THOUSANDS of lines, currently had a production instance, so needed it back up asap. This is fixed now . Was a bug in the polling in the UI.

Thank you.

@girish said in Attempted to restore Cloudron 9.0.12, receiving error when loading backup configuration and hitting Restore button: @d19dotca I tried to reproduce this but I couldn't figure where to set this IP allowlist in iDrive e2. Maybe it's only for paying customers since I am on the trial plan ? Hi Girish. This link can help, assuming it isn’t gated to paying customers (I’m not sure if it is or not), but hopefully this provides some instructions for setting up an allowlist. https://www.idrive.com/s3-storage-e2/faq-buckets#ip-allowlisting I suspect you’re right though, that it is sending back a non-XML response to provide a response message that it’s forbidden from accessing it. I understand this use-case may be rare, but I think if there’s a way to improve that error handling, it may help others too because at first glance it’s really not clear where the issue could be coming from.

Thank you!

@joseph thanks! No, no errors inside of docker image logs. /home/yellowtent/platformdata/logs/mail/*.log - from what I can see, that is the same logs I can see inside of Docker - so I would say there are no (error) logs - from all of the perspective, the server looks perfectly normal... except that it doesn't accept user's messages... I would hope that you bring updated Dovecot to Cloudron 9 and it will self-resolve, but better will just do a restart for the time being...

@shrey said in Error: Domain nameservers are not set to NameCheap: Sorry, my first time with this sort of Subdomain delegations. Subdomain delegation can be very, very tricky. Not all DNS providers even support this. I know that DigitalOcean is very straight forward with adding a subdomain as full Domain and works well. But for example Cloudflare or Hetzner do not even allow adding e.g. subdomain.DOMAIN.TLD as a DNS entry.

@SDEInfo fixed with https://git.cloudron.io/platform/box/-/commit/e87d2e1218ce0e6d5a9ee89e57976e459b73c7d4

@trend-1 our mail server was having the same trouble. DO has blocked outbound port 25 (ipv6) wholesale on the network and it doesn't look like they make exceptions. So, the mail server tried to send via ipv6 (haraka prefers ipv6 by default) and wait for sometime to fail. It then tried ipv4 after. For my other VPS, which has IPv6, email was getting blocked in various places anyway because of the "open resolver" issue of IPv6. So, I think 9.0.12 fixes it. Works on both my servers.

FYI this https://forum.cloudron.io/post/39865 is the proper and working way to enlarge /dev/sda3 even on a running srvr.

might be an issue with: https://forum.cloudron.io/topic/14359/cloudron-9.0-beta-bug-reports/151?_=1763769454970

@Beardmann coffee. Drink coffee. Helps me.

Okay, so after some testing I still don’t know why the changes in htaccess disappear. But on one server it works fine, and on the other it reports a 5 GB file size limit — no idea why. At least normal uploads in the web interface now work. However, all my previous tests failed because I was always testing with a shared link that has edit rights. With that, I still get a 413 error and the following message: BadRequest – Expected file size of 3099309687 bytes, but 0 bytes were read (from the Nextcloud client) and written (to the Nextcloud storage). This can be caused by a network issue on the sending side or a writing issue on the server side. So it seems that the upload limit only works for regular logged-in uploads, but not for uploads via share links. Any idea what might cause this difference? Guess this is a nextcloud issue.

@girish Increasing the task memory did it. Issue solved.

I have not noticed this issue yet after upgrading to 9.x.

I updated the post already and added a section at top: For the sake of completeness as it may happen to others: We finally identified an issue in the network configuration, that isolated the internal VM network from the public network. Disabling the isolation solved the issue at hand. We are now figuring out another way to isolate the VM itself. you can decide if you wanna decline/resolve it or just publish and directly close it