I changed the accuracy and it got better.
There is still a major delay of couple of minutes from "location data is received by traccar server" to "showing it on the traccar map"
Hello @Shai
The second level domain, also known as @ in most DNS providers e.g cloudron.io has a different propagation time then third level domains aka. example.cloudron.io.
This could take up to 24 hours or more, depending on the hosters default TTL for the domain or what you've set.
Might even be resolved now when you retry it after 7 hours.
@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.
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.
@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
@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?
in fact in the directory only the dir data is left and it is empty but root:root is the owner
[image: 1603584552046-fe2b1d58-3d79-4c28-bc6d-17bc1821095b-image-resized.png]
after rmdir /home/yellowtent/appsdata/f266ef68-b01b-4a9e-954e-b8bc68010672/data
the uninstallation went well
