@mehdi thanks for reporting, this is fixed now. Next time a separate thread might be better to track those things if possible.

@omen OK, I figured out how configure Fastly now... Please configure it like below: Enable TLS - Yes Verify Certificate - Yes Certificate hostname - In my case, it is wildcard. But since you use the 'manual' provider, the hostname is subdomain.example.com. SNI hostname - this is subdomain.example.com. With the above settings, fastly serves up pages fine on http. [image: 1640323796482-c787fbfb-57bb-4793-a100-3da1015ba6a5-image-resized.png] One thing to remember is, because you are using "manual" DNS provider, Cloudron requires "http" callbacks for Let's Encrypt to work. I am not sure how this works in fastly, does it allow you to have some URLs that are not "cached" ? I guess one way is to call the Cloudron app subdomain as "website.domain.com" but the domain in fastly should be something else like "realwebsite.domain.com" (meaning, name it different). This way, manual setting on Cloudron can continue to use HTTP reliably to get certificates. If you want the domain names to be same, you have to use one of the automated DNS providers in Cloudron.

@joesitsolutions said in Restoring app from backup?: I have the .zip file. Cannot figure out why I keep getting "backupFolder path is protected" You can only create backups to specific paths on the server. Many of the paths are "protected" to make sure that the folders won't get overwritten by updates or are used by the system. This is just a hardcoded list of paths: const PROTECTED_PREFIXES = [ '/boot/', '/usr/', '/bin/', '/lib/', '/root/', '/var/lib/', paths.baseDir() ]; (the baseDir above is /home/yellowtent/). You cannot create backups in subdirectories of the above paths. I understand you are using restore here though and not backup The restore logic uses the same validation logic for paths and you have copied the backup to under /home/yellowtent/. Instead, copy the backup in some path like /mnt/backups/ or /srv/backups/ and try to restore, that should work.

This got sorted out by @ntnsndr by contacting linode support. The VM had to be rebooted after linode unblocked port 25.

It's back online now! Agree about having a second source. Ideally, we can have some self-hosted docker registry which is used as a fallback for such situations.

I created a new topic for reset of the conversation at https://forum.cloudron.io/topic/6191/wp-alias-domains

BTW, 3.1.0 is the most recent image now - https://forum.cloudron.io/topic/6178/new-base-image-3-1-0

@d19dotca great catch! I was a bug in the client side code. It is fixed now and will be part of next release.

@robi said in Adding multiple aliases to an app Fails: it seems to wait for ALL the domains nameservers to respond, when it could do well with just the first. The rest will catch up in a few seconds as they update too. this is done because we cannot predict which nameserver will be used by Let's Encrypt or the browser. By waiting on all nameservers, the whole process is more reliable. Especially for the end user, if the browser hits NXDOMAIN it can get complicated to clear the DNS cache.

This is being take care of in support .

@charaoh On Cloudron each app runs in a container. So apps cannot access the host (ssh) and vice versa. You can instead upload the files and access the files using the Web Terminal - https://docs.cloudron.io/apps/#web-terminal . This "terminal" is run in the context of the app container.

Which app are you referring to or are you referring to the system wide SMB server? For the latter, this is not supported by Cloudron. Installing and configuring other services on the same server where Cloudron is installed, will eventually break either Cloudron or those services. Maybe you can briefly explain the use-case you have on hand?

There is an allow list file, but you have to access it from ssh. It should be in the docs.

@jodumont said in Docker Swarm or MultiHost Support?: It is possible to have 2 cloudrons under the same domain.tld ? The main domain needs to be different, in order for the dashboard to have a unique URL for each Cloudron (the my.domain.com). It could however be a subdomain for one of the machines. And you could afterwards add the main domain to the second machine, in order to install apps on it too. For example, you could have Machine 1 with main domain domain.com, management dashboard on my.domain.com, and apps on app1.domain.com, app2.domain.com Machine 2 with main domain machine2.domain.com, management dashboard on my.machine2.domain.com, and apps on app3.domain.com, app4.domain.com

@mastadamus Can you add that as a feature request and mention this thread?

@nebulon no worries.. I found it by searching the admin page

Hey, Thanks for the quick response (and to Johannes for the support ticket solving too). That is a fine workaround for me until there's a cancel button implemented some day. At least I can do some tests now, thanks guys great job.

@girish I found this when i clicked update: [image: 1639218382101-61f3d999-30ce-405d-9639-1e1c26465759-image.png] Both my apps are running and are accessible. I now tried stopping the Nextcloud instance and started it. And it the app the 1 dead app is now 2 alive and 0 dead. Now i could update normally. Not sure what i missed in the first place but now works. Thanks for the help

@d19dotca @Lonkle , had the same issues with Cloudron installation on vpsdime. Fixed it using the same workarounds in this thread. Seems to work fine now. Not sure if there will be any issues in the future..