@ReessKennedy said in Digital Ocean Issues after altering Droplet name?: Changed name of droplet. but this is a superficial change that I think only occurs in a Digital Ocean database just for labeling and does not impact any server config. In DigitalOcean, the name of the droplet is also the reverse/PTR address for the IP address. Just something to remember, this is not the reason your Cloudron is unreachable though. All systems seem like they are working fine Can you also run cloudron-support --troubleshoot on the server?

Yup, you are right that Cloudron needs IPv4 currently. IPv6 only setup is coming only in Cloudron 8

@AmbroiseUnly Good find... Cloudron does not support IPv6 only setups yet. But it's coming in the next release (Cloudron 8).

@ccfu it is working now. I guess it needs some time to take effect. Thanks!

What @Dont-Worry said. As long as it' mountable on the server as Cloudron Volume, it should work without a problem. With NAS and network storage, one thing to keep to mind is the flakiness/stability of the network. Apps can behave erratically if the attached storage is not stable.

@Recliner2042 good catch! Fixed in https://git.cloudron.io/cloudron/box/-/commit/f386c326e2c7645eed77bc171c4913fbd99ef2d3

@victorlinares94 GoDaddy has put some new limitations on API access. Please contact their support. https://www.reddit.com/r/godaddy/comments/1bl0f5r/am_i_the_only_one_who_cant_use_the_api/ " We wanted to inform you that we have recently updated our Domain API requirements. As part of this update, customers are now required to have 50 or more domains in their account to utilize the API. Unfortunately, as you currently only have 1 domain in your account, access to the API is blocked for you. " See also: https://www.reddit.com/r/godaddy/comments/1chs1j8/godaddy_access_denied_via_apicall/

@mac3388 The backup file should have had an accompanying json file which tells Cloudron how to handle it, did you back that up as well?

Did you double check the name servers with your domain registrar? Sometimes we miss the simple stuff. Maybe you did input them but chose the option where you use the registrars records and not your custom set ones.

Please see https://docs.cloudron.io/email/#server-status . Specifically https://docs.cloudron.io/email/#ptr-record and https://docs.cloudron.io/email/#outbound-smtp

@girish Done: https://forum.cloudron.io/post/89451

Hi Girish, First, thank you for taking the time to provide such a detailed and technical explanation. I genuinely appreciate it, as I find it very insightful. As I mentioned in an earlier post, the TMP directory that fills up the most is indeed Emby's because we move a lot of data there. We add a substantial amount of content regularly. However, it's not just Emby that has this issue. Several other applications also exhibit similar behavior. The list of these applications, which I posted earlier, includes: Emby N8N Cal Uptime Kuma OpenWebUI Penpot And a few other unidentified applications This list is not exhaustive, but these are the primary culprits. To answer your questions: a) Yes, the directory that had around 83GB of data was indeed Emby's TMP directory. This directory fills up quickly as we add more content. However, other applications also contribute to the storage issue, just not at the same scale as Emby. b) I add files to Emby using the File Manager. We do not use Emby's upload feature, even though we have an Emby Premiere instance. We prefer to manage our files directly through Cloudron because we trust its infrastructure and prefer to use it as intended. I understand that the issue is not inherently with Cloudron itself. My reflection was that this docker-volume issue only started appearing after I added a new storage volume to my server. To clarify, I added an OVH NAS-HA as a new volume to the server, and then I mounted it on Cloudron through the admin panel. This docker-volume did not exist, or at least was not noticeable, before this addition. Since moving Emby to the new volume, I see my data on the new volume as expected, but it also appears to be duplicated in the TMP directory on the server's disk. This duplication was not happening before the new volume was added. Hence, my hypothesis is that there might be a configuration that wasn't fully adjusted to accommodate the new volume, causing files to be stored in both locations. I'm not entirely sure how the backend works, so these are just observations and hypotheses based on my use of Cloudron.

Building on this, this would be a great feature and eliminate a lot of manual work. We typically place a security.txt file in each site, but the ability to just deploy this would be great and configure via the .well-known configuration. I could be wrong, but could this be done at the "platform" level or would it have to be in each package? For example, pretty easy in the WordPress Developer Package, where we just create the folder, drop the file, and add a .htaccess redirect for domain.tld/security.txt to domain.tld/.well-known/security.txt.

If you want some CI/CD inspiration with GitLab + static asset hosting, you can look at our docs repo. It builds using mkdocs and then pushes the build to surfer . See https://git.cloudron.io/cloudron/docs/-/blob/master/.gitlab-ci.yml?ref_type=heads . The build server is a separate VM running gitlab runner (but only costs around 5 a month).

It is as @humptydumpty said. Cloudron 8 (not yet released) has IPv6 only support.

@girish got it, thanks

@girish Confirming that the issue was unrelated. It was very helpful to be able to manually refresh certificates and then view the log files. Thanks!

@Ritesh yeah, I would disable it. It's not required for a Cloudron install.

@overholt said in Linode - upgrade Cloudron to Ubuntu 22.04 & NextCloud 28/29: It looks like Akamai/Linode does support 22.04 now We weren't aware that Linode was providing Cloudron via their Marketplace. Great to hear

@girish Thank you very much !