Hello,
Minecraft Forge 47.2.0 for Minecraft v1.20.1 became stable now.
Best Regards,
Hello,
Minecraft Forge 47.2.0 for Minecraft v1.20.1 became stable now.
Best Regards,
Excellent, nice to hear! I'm really excited about some of the features!
@marcusquinn Thank you for the link, wasn't there when I initially checked it yesterday.
Whatever caused this, either a Cloudron update or some self-solving stuck/bug in NextCloud fixed it. It works now.
I doubt that you are talking about the software Cloudron nor an app that you host via Cloudron so this sounds like you are in the wrong forum.
Thanks for the feedback although it's still open why there's a 4 month old logfile if logging was ever done to /dev/stderr.
Anyway, in the meantime I opened a GitHub issue at their repository and we found further indications what is wrong. I'm awaiting feedback from the dev to see why this should be a general write issue with my NextCloud instance when uploading and editing files works.
Could it be that the logging of Nextcloud is just broken within Cloudron? I just noticed and tried a few things but at the end, I don't get any PHP warnings or errors; neither in the container's log nor in the /data/nextcloud.log
file. Even what I try might not throw any critical errors or warnings, I bet other stuff would throw some as Nextcloud is quite complex.
What I tried to make debugging work:
'debug' => true,
as third line of config (first line of the array)'loglevel' => '3',
to zero (should be documented that Cloudron has a different default value for it than the standard NextCloud documentation mentions)'logfile' => '/dev/stderr',
to //'logfile' => '/dev/stderr',
(but it looks like it got reverted?! -> maybe this is the cause why the file /data/nextcloud.log
doesn't get updated; last update is 4 month ago; was this changed?)So basically I don't get the issue debugged because the debugging is not working.
EDIT: For some reason I get Aug 19 19:25:31 {"reqId":"Wg5Sh91vaYVjy6qvqFIW","level":3,"time":"2023-08-19T17:25:31+00:00","remoteAddr":"","user":"--","app":"PHP","method":"","url":"--","message":"fopen(/dev/stderr): Failed to open stream: No such file or directory at /app/code/lib/private/Log/File.php#84","userAgent":"--","version":"27.0.2.1","data":{"app":"PHP"}}
errors now (I had protocol view of NextCloud open but not at that moment so either it comes from elsewhere or the log is quite delayed). I will have to check this later.
This week the forum was way more reliable for me except one or two cases where the forum software told me I have no internet connection. So I wanted to report this issue as resolved but then I faced just right now this (502 Bad Gateway errors; refreshing several times helped):
Interestingly, I also face at the same time issues with Microsoft Office 365 services. Looks like they share something in common.
@girish Can you publish the new version of the app please? Then I can check why the download of the models for the Recognize app doesn't work. I think it might be related to some path being read-only.
Hello,
I just checked the filemanager for a Nextcloud 27.0.2 app instance and found out that I have a file called htaccess
(no dot at the beginning of the file). After checking this from the terminal, I indeed see a ../data/htaccess
file. It's not a display bug of the Filemanager.
I found no related issue for Nextcloud so is this a problem of the NextCloud setup/template by Cloudron? Of course this is unlucky then because it means it was ignored.
Best Regards,
I will do that, thank you.
Hello,
I just noticed that the Teamspeak server app and MonicaHQ for example have lines like this:
This app packages MonicaHQ 4.0.0
This app packages MonicaHQ 3.6.0.
Are these copy and paste errors? My understanding is that an app package can just package 1 version.
Best Regards,
@erikscholz I can't say anything about that. Sorry! I just mentioned Contabo because I have very good experience with them and it looks from other posts in this forum that they support it. I just tested it on one of my servers with them (multiple years old) and it's supporting it. So if my older Contabo server support it, I think Netcup rootserver and Contabo should support it quite likely on their newer hostnodes. You could ask them, I'm sure they give you a quick answer.
Backups are fine now. it created a backup in the night and it succeeded. Only the backup from yesterday is broken according to the log and I still see the old (non existing) backup logs in the dropdown. So just a tiny bug and the backup system itself works fine.
Thanks for confirming this and explaining how it works in the background!
I would check out Netcup or Contabo. In case you go with Hetzner, you should check their availability for emergencies in the night/morning hours (e. g. outside the typical 9 to 5 working hours). For netcup, you got an emergency hotline that is free in case the issue is on their side and for Contabo I had good experience where they fixed a technical defect in the night in 5 minutes after my email. I'm not sure if Hetzner provides the same level. Of course it's just relevant if your services are business-critical or you need a certain reliability. I think none of these 3 providers are known for having a bad uptime.
Hello,
I added the line 'debug' => true,
to my config.php
file. After saving and restarting the app, the line is kept but it is changed to false instead of true. According to the docs and according to Nextcloud docs, this should work. I'm on NextCloud 27.0.2. Is this some bug in Cloudron? I need this to debug an issue with the Recognize
app. For some reason the download of the trained models is broken.
Best Regards,
Hello,
I just noticed that the system view with the overview of the CPU, Memory & Disk usage is lost after restoring from a full backup. This isn't too bad and could be expected behavior but it's not mentioned in the docs at https://docs.cloudron.io/backups/. In my case it's no big deal although I would need the old data to answer a question about a bottleneck I face in the forum so now I lost that data to answer it.
Best Regards,
Hey @michaelpope,
thanks for your reply! Appreciated!
@michaelpope said in Restore process tested - what happens if ownership of backup files was wrong?:
For 2.1, Not with the Cloudron Team, but (2) sounds like the ssh keys that cloudron uses for support aren't there. I'm guessing you authorized them supporting you in the past, but on the new box, have not authorized them, or something like that.
Yes, I think so too. It looks like this error is thrown everytime I call the support page of Cloudron so should be fine as it is like you suspected.
For 2.2: I never added a volume to the previous or current instance. When I check the page, it is just empty (no entries for the table at /#/volumes
).
Maybe it is related to the OS updates I applied on the previous instance (trying to fix a turn service issue) but from the error messages it sounds unlikely as it's just Cloudron-specific messages without direct OS/docker context.
Just noticed that in the backup overview there's aso a red error: Task was stopped because the server was restarted or crashed
. Could be from the reboot after Cloudron install?
Hello,
I just tested the backup and restore procedure of Cloudron v7.5.0 due to @scooke recent forum thread.
For that I downloaded the full backup in /var/backups of this date, took a copy of the backup configuration, reinstalled the VPS with an Ubuntu 22 LTS image and executed the Cloudron setup there + uploaded the backup files. IPs + domain were the same before and afterwards (no change). That went fine and I was able to execute the restore button. Then the dashboard was down for 2-3 minutes and I noticed I forgot the warning in the orange box under https://docs.cloudron.io/backups/#restore-cloudron. Then I changed the permissions of the directory + files to yellowtent:yellowtent
. Dashboard was available again and the apps are running. I have three questions about this:
Aug 16 18:26:08 box:shell support (stderr): grep: /home/cloudron-support/.ssh/authorized_keys: No such file or directory
"2023-08-16T16:14:54.440Z box:shell startTask (stderr): Running as unit: box-task-908.service
2023-08-16T16:15:00.041Z box:scheduler sync: adding jobs of 8856cefd-14a0-4142-a62a-e3edea36dbae (nextcloud.<removed>)
2023-08-16T16:15:00.047Z box:scheduler sync: adding jobs of 8856cefd-14a0-4142-a62a-e3edea36dbae (nextcloud.<removed>)
2023-08-16T16:15:00.111Z box:scheduler BoxError: (HTTP code 400) unexpected - invalid mount config for type "bind": bind source path does not exist: /home/yellowtent/appsdata/8856cefd-14a0-4142-a62a-e3edea36dbae/data
at Object.createSubcontainer (/home/yellowtent/box/src/docker.js:413:28)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
2023-08-16T16:15:00.112Z box:scheduler BoxError: (HTTP code 400) unexpected - invalid mount config for type "bind": bind source path does not exist: /home/yellowtent/appsdata/8856cefd-14a0-4142-a62a-e3edea36dbae/data
at Object.createSubcontainer (/home/yellowtent/box/src/docker.js:413:28)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
2023-08-16T16:15:00.120Z box:apphealthmonitor app health: 1 running / 0 stopped / 3 unresponsive
2023-08-16T16:15:00.122Z box:apphealthmonitor app health: 1 running / 0 stopped / 3 unresponsive
2023-08-16T16:15:02.258Z box:oidc Creating OpenID storage adapter for Session
2023-08-16T16:15:02.258Z box:oidc load: model Session based on /home/yellowtent/platformdata/oidc/Session.json.
2023-08-16T16:15:02.259Z box:oidc load: failed to read /home/yellowtent/platformdata/oidc/Session.json, start with new one.
2023-08-16T16:15:02.262Z box:oidc Creating OpenID storage adapter for Client
2023-08-16T16:15:02.281Z box:oidc Creating OpenID storage adapter for Interaction
2023-08-16T16:15:02.281Z box:oidc load: model Interaction based on /home/yellowtent/platformdata/oidc/Interaction.json.
2023-08-16T16:15:02.281Z box:oidc load: failed to read /home/yellowtent/platformdata/oidc/Interaction.json, start with new one.
2023-08-16T16:15:02.282Z box:oidc save: model Interaction to /home/yellowtent/platformdata/oidc/Interaction.json.
2023-08-16T16:15:02.289Z box:oidc save: model Session to /home/yellowtent/platformdata/oidc/Session.json.
2023-08-16T16:15:04.333Z box:shell startTask (stderr): Finished with result: success
Main processes terminated with: code=exited/status=0
2.3 2023-08-16T16:17:00.065Z box:scheduler BoxError: (HTTP code 409) unexpected - Conflict. The container name "/8856cefd-14a0-4142-a62a-e3edea36dbae-housekeeping" is already in use by container "5a97c1b276294c53f398bf13435e10423074ddba6c1d77653f874fb526f515a0". You have to remove (or rename) that container to be able > at Object.createSubcontainer (/home/yellowtent/box/src/docker.js:412:62) at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
3. In the backups view, I see the old backups that I didn't upload nor save. They are lost in data nirvana now (as expected from my side). Will the non-existing backups getting deleted from the list in the next task/job run?
Should this be investigated (I see some other errors as well with similar wording as e. g. no. 2.3 or where it complains that mongodb, postgresql, sftp were not up yet although it was expected)? Beside of that, it was a straightforward process. Just a tiny UI improvement would be great: A way to download the full backup + backup config with 1 click (no need for sftp to download the /var/backups/2023-08-16[...]/* files).
Best Regards,