Cloudron Forum

Thanks for looking into this @timconsidine.
I thought about your comments and then I installed LibreChat. I will see how I get on with that first.

Thanks @james I did try that before, then restarted the app and it didn't work, however I now unmounted then deleted the volume (*.idx, *.dat, *.vif (left *.uuid) and restarted it and it seems to have worked - I can see over 15 volumes.
I'll see how it goes with the backups tonight!
Thanks for your help

OK, I think I have worked it out - use the Cloudon CLI...
cloudron env set --app localai.mydomain.com LOCALAI_API_KEY=xxxx
Thanks

Hi @eyecreate I have installed your localai app, all went well.
I have one issue when I try to connect my LibreChat to it - where do I change the authentication key?

If I test it with I get an expected auth error...
$ curl https://localai.xxxx.net/v1/models
{"error":{"code":401,"message":"An authentication key is required","type":"invalid_request_error"}}

Hi Forum,

I can't seem to get Seaweed to use my available disk space or more than one bucket. Has anyone had the same issue?

Background: I have been looking to replace my Minio S3 service with either garage SeaweedFS or RustFS and choose Seaweed. My main use case is to use S3 for tarball backups and I have a server with 14TB of space to use for this. Minio was good for this, however it no longer has a future in the OS community. SeeweedFS works well and is good to use, plus it is stable. RustFS also works well, has fewer features (that I probably don't use) but is not stable yet.

Issues: After installing Seaweed it works fine as installed, but it appears to be set to a maximum useable limit of 8Gb and also I get errors if I try to use any second bucket at all - no free volumes. I see in file manager and the Seaweed dash that I already have 8 volumes. The my first Cloudron Server backup saves fine, but fail after 8 Gb, my second Cloudron server fails if I try to set it to a different bucket with the no free volumes error in the logs.

Using weed volume.list I can see the volume size limit is set to 1024 MB (also visible in the dashboard) and the max number of volumes is set to 8. I have not been able to increase these and it appears that the Cloudron App has set some parameters in the start script which I haven't found a way of overriding in env.sh.

I suspect I need to override the defaults to expand the usable space, for example I could do 430 volumes × 30,000 MB = 12,900,000 MB => 12,900,000 MB = 12.30 TB of raw data storage, leaving headroom for indexes etc, but I can't seem to override these in the Cloudron App:

• volumeSizeLimitMB - I understand there is a build limit to 30Gb (30000) to do with 4 bit sizes

• maxVolumeCounts - either to 0 for auto or a sufficiently large number that x the Size uses the available disk space

I have tried numerous options in env.sh and none change the setting, even if I remove the existing files, volumes and collections. Options include:
export WEED_VOLUME_ARGS="-max=126" or export WEED_MASTER_ARGS="-volumeSizeLimitMB=30000 -maxVolumeCounts=hdd:126"

I can achieve this with a custom start script called from env.sh (which shows it is being run), but of course this breaks everything Cloudron. Is there a way to do this, or am I missing something?

If not, can you expose the variables so that we can achieve using the available disk space and multiple buckets (collections)?

Thanks in advance!!!

Hi @timconsidine,
Did you ever share the AnythingLLM?
I was interested in trying it, but I can't see it on https://ca.cloudron.io/

It would be great to spin it up and compare it to the OpenWebUI and LibreChat

Thanks @fanvyr this saved my bacon
My box got 'stuck' upgrading from 8.x to 9.x so I used SSH to reboot.

db-migrate check as above said there were 11 to go, starting from:

[INFO] Migrations to run: [
'20250618200400-fix-charset-collate',

db-migrate up finished them all and a reboot got my box running again. Thanks for posting this!

Hi, me too!
We use Freescout and want to host this on our Freescount VM so we keep our data in house.

Thank you @girish and @marcelfolaron, I updated my test system with the fix and it worked fine, so I have updated production ones too.
That was resolved remarkably quickly and saved me a lot of strife, amazing, thanks again

@nebulon Would you mind checking this?
I see you are working on PHP 8.2 for Leantime

@marcelfolaron can you add your wisdom please
Could our issues be permissions or ports?

Leantime have posted:
Docker configuration updates
Due to the user/group updates on the docker image there is a small chance you run into file permission issues on existing volumes check https://github.com/Leantime/docker-leantime?tab=readme-ov-file#common-issues--solutions for setting the permissions correctly.

Additionally we updated the internal port to be 8080. Please make sure your docker compose files reflect the recent changes

Highlights
For a full list of 3.4 updates see: https://github.com/Leantime/leantime/releases/tag/v3.4.0
==> Fixed date issue in milestone, timesheet, sprint generation <==
Fixed cron handler for long running schedule:work job to be able to run cron jobs in docker
Misc other fixes

I believe the update broke the app, probably when going from 3.4.2 to 3.4.3. (but it could have been earlier and not spotted)
Looking into the upgrade process I see there are three issues:

1. Changes in permissions - related to changes in Docker configuration updates - probably responsible for the bland 'Server error' issue
2. Internal port changed to 8080, probably responsible for the ECONNREFUSED 172.18.16.53:8080 issue
3. PHP 8.2 required, Laravel no longer supports 8.1 - no idea if this is an issue, are we on 8.2 already?

Hi all,
Leantime is only partially functional after upgrade to 3.4. For example you get 'Server Error' when trying to add a milestone.
The logs show various errors after restarting the app.
E.g. Healtheck error: Error: connect ECONNREFUSED 172.18.16.53:8080
This is consistent across 2 installations on different boxes, clients and domains.
The normal restart, reboot etc do not fix the errors.
Restoring a backup to a fresh install on a different VM did not either.

Hi, sorry, I missed your question, yes @jdaviescoates is correct Marcel is.

If you need a license to integrate this I'm sure Marcel will oblige.
As it is an additional cost option, would you approach this in the same way as Cloudron did for FreeScout, where by default it installs with the app managing its own users, unless the license is purchased?

Hi @nebulon I think the app does support OIDC, at least according to this article https://marketplace.leantime.io/product/installation-auth-provider/
Choice of LDAP (OL or AD), OIDC or Google SSO. Works with the open source installation: https://marketplace.leantime.io/product/leantime-open-source-installation/

Thank you

Hi @nebulon I think there's a fix for this on Github, revert the changes in app/Core/Console/ConsoleKernel.php and apparently the error will disappear. See https://github.com/Leantime/leantime/issues/2710

Meanwhile I have chased @marcelfolaron for support.

@nebulon, version 3.2.0 has an issue that breaks Leantime if upgrade from an earlier version without first disabling all the plugins and deleting some files/folders. All very well, however the first you know about this is when the automatic upgrade has run and broken Leantime, by which time it is too late.
@marcelfolaron has kindly released a fix in version 3.2.1 which will allow us to get back up and running, however we cannot manually install it as we don't want to break the Cloudron updates system.
Can you give an idea on when you might be able to pull this new version?
Thank you for your help