Usually in email providers, there are two kinds of setups - identity based setup (to set up relaying a single email address) or a domain based setup ( to set up relaying for the entier domain). You have to set up domain based setup. This is because each app on Cloudron sends email with potentially a different email address (in the username portion).

I ran into a similar issue today, here is my solution: Note: I manually created a n8n-uploads folder in my case. In n8n, using the "Read/Write Files from Disk" action: File Path and Name: /app/data/n8n-uploads/file.jpeg /app/data/file.jpeg works out of the box, but I wanted to store all my files in the same folder. [image: 1720170441738-514706b4-197c-43e1-8c36-c4c69fc6498a-image-resized.png] Here is a video: https://www.loom.com/share/5e6bccdbd19842a489cc10f90ea871d4

I recommend just setting up 2FA for Cloudron dashboard. Enable mandatory 2FA as well (https://docs.cloudron.io/user-directory/#mandatory-2fa).

i think the unbound DNS worked; seems ok now. thanks!!

You can read more about ports and firewall setup with cloudron at https://docs.cloudron.io/security/#cloud-firewall

It's ok, resolved thank you very much

OK, I made this change now: - "description": "This will uninstall the app immediately and remove all its data. The site will be inaccessible.", + "description": "This will uninstall the app immediately and remove the app's data. The site will be inaccessible.", The usage of its in English is always tricky. If you care, "its" is possessive and "it's" is short forum of "it is" .

@nebulon Thanks to you and @girish for explaining this.

@dsp76 multi part copy is a different API call from multi part upload

This worked thanks

To add to what @necrevistonnezr said, add the hard drive as a Cloudron volume and use https://docs.cloudron.io/apps/#data-directory to move the app's data into that volume.

@philkunz said in No support for simply uploading a backup through the web ui?: Ok got it. Is there a particular reason, why a simple upload through the webui is not supported? In some ways, this can be considered a security issue. If we had some bug in Cloudron code, then one can import/delete your existing data in the app. This is also why we don't allow deleting backups via the web ui. But (atleast I) have come around to this a bit. Maybe this can be considered a usability issue. We just need to figure out some safety hatch when user uploading a backup (maybe require 2fa, reenter password etc).

Good to know! Thanks

@bmann This helped me after updating to 8.0 which broke IPv6 for some reason (I'm also on OVHcloud)

Hi All Work it out IPV6 on the OS level Need to make sure that is off ( will look at how to make sure the OS stop using it )

The issue here had to do with something in JupyterHub container creating a massive number of folders recursively. Think 300k folders or something. Nuking all that stuff, made backups work again.

Handled with the email support. Thanks for the very fast help!

@potemkin_ai thanks for reporting. It seems nfs-common depends on rpcbind which starts the service at port 111. rpcbind is only needed for NFSv3 . I have disabled rpcbind in the next release (8.0.1) . Cloudron only supports NFSv4 out of the box.

I just waited 24 hours and now everything is working

@gerard said in Restore v7.7.2 (Ubuntu 22.04) backup to v8.0.0 (Ububtu 24.04) system: The release notes state an "initial support for 24.04" that doesn't sound like it's fully supported yet. It should mostly work but we are just being a bit cautious here There's a limit to how many VPSs we can test the installation on. We tested on the popular ones and seems to work, but one never knows. The upgrade path for you would be to upgade to v8. Then later in 2-3 weeks time when v8 is considered more stable, you can migrate to a fresh ubuntu 24 with cloudron backups.