Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.


Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Bookmarks
  • Search
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo

Cloudron Forum

Apps | Demo | Docs | Install
R

rnphil

@rnphil
About
Posts
9
Topics
2
Shares
0
Groups
0
Followers
0
Following
0

Posts

Recent Best Controversial

  • Issue with Default CRON Configuration for FreeScout App
    R rnphil

    Hi Cloudron team,

    We've encountered an issue with the default CRON configuration for the FreeScout app on Cloudron.

    The default CRON script installed for FreeScout is as follows:

    #!/bin/bash
    
    set -eu
    
    cd /app/code
    
    echo "=> Run cron tasks"
    
    # when run with --no-interaction it will not daemonize (unlike in the supervisor config for it)
    /usr/local/bin/gosu www-data:www-data php artisan schedule:run --no-interaction
    

    The problem lies in the --no-interaction flag. According to FreeScout's official documentation (link), this flag should NOT be added to the command, as it prevents the background queue:work daemon from running. This behavior is exactly what we're experiencing.

    Unfortunately, we cannot modify the default CRON file in /app/pkg/cron.sh since it is read-protected. Additionally, when we attempt to add the correct CRON command to the Cloudron CRON section:

    * * * * * php /app/code/artisan schedule:run >> /dev/null 2>&1
    

    It results in duplicate CRON jobs being executed, further complicating the situation.

    Could you please advise on how to resolve this? Ideally, we need the default CRON script adjusted to align with FreeScout's documentation or an alternative solution that allows us to override the existing configuration without conflicts.

    Thanks for your assistance!

    Best regards,
    Phil

    FreeScout

  • Correct chown and chmod for /platformdata, /boxdata, and /appdata After Changing Default Data Directory
    R rnphil

    Hi everyone,

    We recently changed the Default Data Directory in Cloudron, but it ended up causing permission issues, so we had to revert the changes and manually adjust the permissions. Since then, some services, including PostgreSQL, are no longer working correctly.

    For example, PostgreSQL fails to start with the following error:

    Feb 19 13:42:15 ==> Detected existing installation
    Feb 19 13:42:15 ==> Copying updated config
    Feb 19 13:42:15 ==> Updating existing postgresql
    Feb 19 13:42:15 pg_ctl: could not access directory "/var/lib/postgresql/14/main": Permission denied
    

    We suspect that some file ownership or permissions might still be incorrect, especially in the following directories:

    /platformdata
    /boxdata
    /appsdata

    Could someone confirm the correct chown and chmod settings for these directories to ensure Cloudron operates properly?

    Thanks in advance!

    Support storage

  • Issue with Default CRON Configuration for FreeScout App
    R rnphil

    Hi @girish,

    Thank you for your prompt response, the technical stuff seems correct now that you mention the supervisor.

    The main issue we had is that the queue was not running.

    I've just checked the supervisor and see that the artisan-queue was crashed.

    /app/code# supervisorctl status
    apache2                          RUNNING   pid 223, uptime 1 day, 2:46:07
    artisan-queue                    FATAL     Exited too quickly (process log may have deta
    ils)
    
    /app/code# supervisorctl tail artisan-queue
    artisan-queue: ERROR (unknown error reading log)
    

    After removing our CRON command to run the schedule and restarting the Freescout Service I can now see the artisan-queue running. Even though if I do:

    supervisorctl tail artisan-queue
    

    I still see

    artisan-queue: ERROR (unknown error reading log)
    

    Not sure if this is an issue or not, but the queue is now working ✨
    Hope it stays like this.

    Best regards,
    Phil

    FreeScout

  • FreeScout OIDC Support
    R rnphil

    @girish
    Is it possible to disable autoconfigure?
    We use an external one, and it's overwriting our configuration.

    FreeScout

  • FreeScout OIDC Support
    R rnphil

    @joseph
    We use the FreeScout OAuth module connected to Google, and we do not use LDAP. However, every time we restart our Cloudron instance, the provider settings reset back to "Custom OAuth Provider" with the name "Cloudron."

    FreeScout
  • Login

  • Don't have an account? Register

  • Login or register to search.
  • First post
    Last post
0
  • Categories
  • Recent
  • Tags
  • Popular
  • Bookmarks
  • Search