I solved the same symptoms by recreating Personal Access Token for Cloudron. [image: 1642094319690-screenshot-2022-01-13-at-6.18.06-pm.png] Read/Write access under Domains required. Mine just expired after default set 6 months.

@mark_ehm At what stage of onboarding are you? Do you have Cloudron installed and setup already? If not, our demo is a good place to start understanding what the product is/does. https://my.demo.cloudron.io/ (username and password is both cloudron). You would install something like Bookstack. You can login to bookstack with the same credentials (cloudron). You can add users in Cloudron dashboard and those users will get access to bookstack as well. If you already have Cloudron setup and working, then just ignore what I said and follow @jdaviescoates said

@robi yes!

(please read warning in above comment before following instructions below). If you want to make config file changes: docker exec -ti mysql /bin/bash Edit /run/mysql/my.cnf as needed supervisorctl restart mysql It is important to note that the changes to config files are not persistent across container restarts and server reboot. In general, we have not envisioned Cloudron as a development environment, but we do have many devs using it as such. So, if there is interest, maybe we need to improve things for such use cases.

This is possibly a bug, but in general we don't completely test as to what gets enabled/disabled when subscriptions expire. It's quite rare that people keep their servers around when subscription expires. But I will test things out when we cut a new release.

I figured it out. There was an issue in namecheap because after checking the ip adress in dnschecker it had two ip addresses: One was the server ip and the other from namecheap. Now there is only one available after chatting with them.

@meeksfamily06 Cloudron uses unbound and does not use systemd-resolved. You won't see any issues unless when trying to use the mail server (or maybe some apps like nextcloud might act strange when going to the apps section).

@ashkaptsov So, AppGyver's browser UI is going to make requests from the browser to n8n and baserow ? Can you tell us a bit more as to why would it want to do that? In general, adding CORS headers without knowing the app knowing about is a security hole.

@girish so I tried more things and my initial observation cannot be reproduced anymore, so I think I might have been misguided by persistent console logs here. Now I am not able to reproduce the double upload trigger at all anymore in chromium or firefox. @robi can you maybe explain in more detail how to reliably reproduce this? Do you have any additional extensions installed and can anyone else here see the issue?

Ah, thanks for reporting. I have opened https://git.cloudron.io/cloudron/box/-/issues/808 internally .

@joshrb91 looks like the server has nvm installed. Which then hijacked the system node. # which node /root/.nvm/versions/node/v14.17.6/bin/node The error is not very obvious because systemctl status box says running but it's not really running. journalctl -u box -fa shows that it's crashing constantly. The reason for that is the box code runs as yellowtent user.. # su - yellowtent $ node --version v12.18.4 $ which node /usr/local/bin/node It seems there is another node installed in /usr/local/bin also. I renamed that directory to bin-old for now and it brings things up. Generally, we don't support installing external software on Cloudron. Was there any reason you installed nvm on the server? (was it to install cloudron CLI? if so, that's meant to be installed on your PC/laptop and not on the server).

@jtippetts It's hard to tell what is happening. Can you try this: Reboot the server Please check if the IP address of server matches the DNS entries. Maybe the IP address was changed during the process of opening up email ports? Once rebooted, please check the output of systemctl status box and systemctl status nginx. If they are both running, the dashboard should be reachable.

Adding a redirection made things work.

huh for some reason in my last session I did not see the search field but there is one. (Maybe I was just blind ) [image: 1641417954001-094213ff-47fe-41f3-b452-a341a216719f-grafik.png] I take it back, please don't throw stones

logrotate is run via the system cron. You can check these: /etc/logrotate.conf should contain the line include /home/yellowtent/platformdata/logrotate.d in the very end. The file /home/yellowtent/platformdata/logrotate.d/platform should contain /home/yellowtent/platformdata/logs/turn/*.log As for cron configuration, systemctl status cron should say Active/running. There should also be a file /etc/cron.daily/logrotate . Other than that, it can only mean that turn server generated a massive amount of logs in a single day (seems quite unlikely but who knows). Does it rotate if you run logrotate manually? - Run /usr/sbin/logrotate /etc/logrotate.conf ?

@mehdi good catch, will fix!

@hamann ah actually this bug is already fixed with https://git.cloudron.io/cloudron/box/-/commit/cefbe7064f4c7b31fb93bbf7ed85bf916aa5cf39 but pending a release. For the meantime you could tweak the file manually at /home/yellowtent/box/src/apps.js and then systemctl restart box or enable the mailbox for that app temporarily.

@rmdes I ended up setting up a local backup for Cloudron and use RClone to handle the backup. I've used RClone for years with no issue, and since going this route, no issues with my Cloudron backup.

@d19dotca thanks man, I’ll look in to your links and also take a look at the app-dev flag of people and see what I figure out! Thanks!