Cloudron Forum

For the record, since the communication on this went private.

The issue was solved by manual intervention.
I have two takeaway messages:

1

If mysql doesn't come back up, it is possible to
remove /home/yellowtent/platformdata/mysql (this is where the mysql addon stores it's data) and restart the box code using systemctl restart box.
(Do this from outside the mysql container) This is apparently non-destructive.

This fixed the first machine which hung up as it ran out of disk space (and this didn't change as space was freed up again)

2

• Do not upgrade box or any app while there's not plenty (5 Gig perhaps) of free space. It seems as if cloudron apps can get stuck in a bad state when space runs out while doing system things [DB migration, backups, updates] (I hope this is correct)
• Monitor space closely, it's cheaper to buy more than to end up fixing a stuck setup...

Hi,

I'm running a cloudron 6.2.4 in which the disk went full (too many images of different versions in docker).

Now the mysql addon (not the ubuntu mysql) doesn't come up again:

2021-03-23T11:43:34.632721Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.23-0ubuntu0.20.04.1) starting as process 11
2021-03-23T11:43:34.646837Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2021-03-23T11:43:34.952073Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
2021-03-23T11:43:34.959894Z 1 [ERROR] [MY-011092] [Server] Upgrading the data dictionary from dictionary version '0' is not supported.
2021-03-23T11:43:34.960213Z 0 [ERROR] [MY-010020] [Server] Data Dictionary initialization failed.
2021-03-23T11:43:34.960380Z 0 [ERROR] [MY-010119] [Server] Aborting
2021-03-23T11:43:35.479431Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.23-0ubuntu0.20.04.1)  (Ubuntu).

Some people report this may happen if mysql is upgraded skipping versions but I cannot know whether this is the case/how cloudron handles this.

Is there a way to recover from this? I cannot use my apps for this reason, not even stopping/starting or recovery is possible.

Update: This is amazing. I encounter the exact same error on another instance in another hosting environment.

Trying to fix this desperately I tried cloudron/mysql 2.3.2, 3.0.0, 3.0.3 and 3.0.6 (3.0.4 seems to be default) but nothing helped.

@mehdi Yes this would be maybe possible with creating my own 'app' (not sure about the privileged NFS mounts).
As I am the only one using it chances are that I would need to maintain it though, requiring quite some regular work to do.

On the other hand though, this work would need to be done anyway when creating such custom container with docker compose or so.

I am a fan of cloudron primarily for it integrating

• monitoring (memory, disk, backups, certificates, containers running) incl. warning emails
• backup/rollback procedure within webinterface
• well thought of update process within webinterface

I like it so much I would love to deploy for example blank LAMP stack and an NGINX as load balancer and mount some data volumes via NFS in, privileged access needed perhaps.

This requires flexibility cloudron doesn't provide for a reason, it's tuned to provide rather simple custom, or packaged webapps. This is totally fine and serves many people well.

I'd like to sacrifice those restrictions while keeping the three points from above, obviously requiring to write my own dockerfiles.

Do you people know of a software that does this? I was unable to find one so far

I upgraded from an old cloudron (5.2.x) to 5.4.1 in steps and meanwhile upgraded my nextcloud instance as the update became available to 19.0.1.

Since then, my shares with other cloudron LDAP users are broken in a weird way

• They can see them under the "Shares" tab but cannot access them
• The shares do not show up on their landing page anymore
• When I (the owner) try to share the folder again with them, I get the error "Path is already shared with this user" in http response)
• The users with whom the folder was shared before the update are not listed anymore in the list "others with access" list
• adding new users to the share works as expected

Did anyone else experience this issue? I don't expect the cloudron devs to act here, it's probably nothing within their reach.

I am wondering whether the subscription is bound to an instance (a vps with ubuntu+cloudron in my case) or to me as a customer.
If the latter is true, this would open options to me to reduce dependencies by having an own VM for mail+webmail and another one for e.g. nextcloud+onlyoffice.

Can you clarify that?

Hello you kind creators of cloudron!

I just followed the docs on setting up onlyoffice document server together with nextcloud and stumbeled upon something that wasn't clear to me when reading it:

• One has to set the two secrets in linux-production.json of Onlyoffice to the same value that's also set within nextcloud settings

Else there will be an error. For me it wasn't clear right away what those secrets are anyway and whether they have a connection or not.

When trying what I tried (leaving nextcloud secret set to 'changeme') the error message 'The document security token is not correctly formed. Please contact your Document Server administrator' is thrown when opening a OO document.

I hope that helps someone

Stay safe and all the best

Hi,

I configured nodeBB with the cloudron mail relay and the relayed-to server is within an internal network directly attached.

It seems that emails are denied by cloudron's relay when the From/Reply-To address nodeBB uses is from a domain that is not @apps.example.com but rather from @example.com.
I want to use this noreply on my second level domain because the "discard" functionality is already configured there.

The nodebb log looks like this; There is no request being logged on the relayed-to mailserver.

 error: Mail command failed: 550 Authenticated user forum.app@apps.example.com cannot send mail as noreply@example.com {"code":"EENVELOPE","response":"550 Authenticated user forum.app@apps.example.com cannot send mail as noreply@example.com","responseCode":550,"command":"MAIL FROM"}