@girish apologies, I jumped the gun on that last post. You were right. I had a look at the box source code (src/scheduler.js, src/docker.js) and the manifest command IS respected by the scheduler. The php artisan schedule:run on my instance came from a custom crontab entry carried over when we migrated from a standalone install to Cloudron over 2 years ago. That entry must have slipped through unnoticed, but it explains everything. After removing it, the scheduler container (now suffixed -housekeeping instead of -crontab.0) correctly runs cron.sh: $ docker inspect --format '{{.Config.Cmd}}' 1af144bb-fbf4-434d-8edd-bb4b95c00ef5-housekeeping Cmd: [/bin/sh -c /app/pkg/cron.sh] Things are working correctly with cron.sh + gosu now I should have caught this sooner. In my defense (barely), the Cron tab of the app doesn't mention that commands run as root. I eventually found it in the documentation at the bottom of the Cron page. A small note in the Cron tab itself would probably help others avoid the same mistake. Cheers, JD

Glad you figured it out. That dos remind me of having many terminal tabs open and sometimes it's hard to tell which is which. I separate them by windows and other tabs in proximity. How can we make them more distinguishable? App name in tab?

I do not have, Ihave deleted the email address and created a new one with the old as an ALias lost too much time with this. Thank you for your help

Just released a new package which fixes the issue. The root problem was a missing LANG environment variable which caused some trouble.

@jcalag why do you think it's risky to update (assuming, you are referring to Cloudron)? you can always reach out to our support@ if update fails. Your instance is almost 20-30 versions behind and is complicated to handle support in it's current state (app packages also depend on cloudron version).

Looks like the latest Freescout release fixes this - Thanks for packaging and releasing it already.

The disk space warning is about the percentage being over 90%. Given the size of your disk, this is not really an issue, since you have plenty of GBs left and freescout does not need nearly that much of temporary disk space. Not quite sure what to make out, that a whole server reboot fixed this temporarily but a freescout app instance restart did not. Is freescout using mailboxes on that same Cloudron? If so and the issue arises again, does it help if you restart the mail service (and maybe freescout)?

Hello @james Thanks for the suggestion! I checked the MySQL service — it has more than enough memory (20 GiB total, only about 40 % used). So it doesn’t look like a memory issue. There are no errors or warnings in the MySQL logs so far, so I think it should be fine. I’ll keep an eye on it for a few days just to be sure. Anyway, thank you very much for your help and your time!

@fbartels Thanks.

Oh! @BrutalBirdie just found the issue https://github.com/freescout-help-desk/freescout/issues/4819#issuecomment-2927528981 Since something was changed in 1.8.181 regarding Take into account APP_SHOW_ONLY_ASSIGNED_CONVERSATIONS option when deleting conversation 8484785 When applying this commit in reverse: wget -O this.patch https://github.com/freescout-help-desk/freescout/commit/8484785a17fa1cd58d46016b45f6822a6adc9b64.diff git apply --reverse this.patch the issue resolves. Since I am not that deep into the freescout code, I can't create a PR right now to fix this. But my method of undoing that commit with a reverse apply proves that there is a regression.

This seems to be an upstream error. From the Freescout web ui app-logs when checking $FREESCOUTAPP/app-logs/app error production 2025-05-26 06:19:54 SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'ratings' cannot be null (SQL: insert into `mailboxes` (`signature`, `email`, `name`, `ratings`, `updated_at`, `created_at`) values (<br><span style="color:#808080;">--<br> This already has been reporte upstream => https://github.com/freescout-help-desk/freescout/issues/4800 The suggested Hotfix => https://github.com/freescout-help-desk/freescout/issues/4800#issuecomment-2903781008 Temporary fix: change line 92 in /app/Http/Controllers/MailboxesController.php to: 'ratings' => $request->ratings ?? 1, Is not possible in a Cloudron setup since /app/code/app/Http/Controllers/MailboxesController.php is read-only. As soon as this is fixed upstream, Cloudron will release the update as well asap.

The 500 status code from your screenshot also hints at a server side exception or crash, maybe worth looking into the app server side logs while that happens. Maybe the crash can then be reported upstream for that faster search module

Can't find anything obvious in https://api-docs.freescout.net atleast https://github.com/freescout-help-desk/freescout/issues is where you ask upstream questions

@rnphil I think the issue is that you have installed Freescout with Cloudron user management. Because of this, it takes ownership of the OIDC provider settings and reconfigures the OIDC provider . If you go to Location section of FreeScout, I guess it says "Cloudron User management" (instead of "Dashboard visibility".) You can try this: take a backup of your current freescout and download the backup configuration file (it's a button to the right of the backup). make a new installation of freescout alongside the existing one. when you install , make sure to select "Let the app manage it's own users" Then, app -> backup -> import . put the backup configuration file from step 1 I think that should sort it out. If everything works, just move your existing install to some other domain and move the new one to the correct location .

@uwcrbc see https://forum.cloudron.io/topic/13260/freescout-oidc-support . Just purchase the OIDC module, activate it in freescout and restart freescout. That's it.

The queue is working, but the fetching is not working now. After a minute of restarting the server, the fetching stopped. 480 479 [2025-01-29 16:31:26] Fetching finished 478 [2025-01-29 16:31:25] Fetched: 0 477 [2025-01-29 16:31:25] Folder: Archive 476 [2025-01-29 16:31:25] Fetched: 0 475 [2025-01-29 16:31:25] Folder: Trash 474 [2025-01-29 16:31:25] Fetched: 0 473 [2025-01-29 16:31:25] Folder: Sent 472 [2025-01-29 16:31:25] Fetched: 0 471 [2025-01-29 16:31:25] Folder: Spam [image: 1738165616523-959c9c52-cd92-4f2a-811c-2c453343c522-image.png] EDIT: After 20 minutes it's now fetching again. Let's see if it keeps working now.

@humptydumpty I think FS stores thing in it's own database but I haven't found any clean up function

@girish Great. Thanks for the clarification!