Cloudron Forum

@dvlexp you have to ask these questions upstream in the n8n forum - https://community.n8n.io/ . We can only provide help here with the packaging aspect of n8n itself. App related issues are best asked upstream.

To follow up, 11GB worked fine too.

image.png

Have you seen https://docs.cloudron.io/apps/#hsts-preload ?

Just in case you like mystery stories, there is a bit more to this tale. It might be connected to time. Restoring to a backup works ok, until the next day/midnight...

Also, the account was also setup on Nextcloud and remains accessible there.

I think it might be due to a OTTP token corruption problem. There is no OTTP used for access via Nextcloud.

Thank you, Girish, for diagnosing and solving this bug so quickly! Backups are working again.

If somebody else has this issue and needs to do the patch, you would go to the operating system for your server and find the file there and edit it. Cloudron also have a support tool inside Cloudron which enables you to temporarily grant ssh access to your server, which would let Cloudron's brilliant team patch it for you.

I try to avoid puttting screenshots in our docs because they become obsolete in 6 months. Given the amount of 3rd party services we integrate with, it's impossible for us to track UI changes across all the services. I just link to the docs like in https://docs.cloudron.io/backups/#linode-object-storage

If something is really super popular, I make a "guide" with screenshots.

@nebulon said in ChangeDetection Error: "The CSRF token has expired.":

CSRF token are to prevent request replay attacks. I don't know much about the context here for this app, but if you refresh the page and perform the action again, does it work then or is this somehow related to the app you are trying to add, which reports this?

Thanks. Waiting and refreshing seems to have solved this issue.

@subven Thank you! I tried again

@LoudLemur If you hit the error page, please post the last few lines of the app logs.

@LoudLemur looks like the DNS record was pointing to a Cloudron which didn't have any app installed on that (sub)domain. If a Cloudron server as such just gets deleted, then the DNS records are not automatically cleaned up, since there is nothing running anymore to do that.

@nebulon said in my.cloudron.tld is not accessible:

nosudo

thank you for eyes and help 😉
this is so weird and like you I don't know that option.

also; etckeeper as not being initiated on that server, so I'm unable to retrace when that change has been made

@girish Thanks for looking into this!

In the mean time I've also been able to get the connection to work by using the "old key" method.

@privsec I enabled all modules you were showing in the screenshots but I cannot reproduce the log file issue. Is there anything else you configured? Also can you check via the webterminal what the permissions of the log file in question are?

This should be fixed in the latest package.

in fact in the directory only the dir data is left and it is empty but root:root is the owner

fe2b1d58-3d79-4c28-bc6d-17bc1821095b-image.png

after rmdir /home/yellowtent/appsdata/f266ef68-b01b-4a9e-954e-b8bc68010672/data
the uninstallation went well 😉

@nebulon Thanks, this was the reason for my problem. After I uncheck "mounted filesystem" Cloudron was updated to 5.4.1