Cloudron Forum

i'm encountering the same Invalid token error when i do surfer put build/* / but if i do surfer put build/* /anyfoldername/ it works fine.
obviously my build need to be in public/ rather than in /public/anyfoldername/

Hi there, just to repport a console error when installing or restarting a Directus app :

\Error: EROFS: read-only file system, mkdir '/home/cloudron/.pm2'
May 21 12:09:55 at Object.mkdirSync (node:fs:1364:26)
May 21 12:09:55 at mkdirpManualSync (/app/code/node_modules/mkdirp/lib/mkdirp-manual.js:48:10)
May 21 12:09:55 at mkdirpManualSync (/app/code/node_modules/mkdirp/lib/mkdirp-manual.js:52:43)
May 21 12:09:55 at mkdirpNativeSync (/app/code/node_modules/mkdirp/lib/mkdirp-native.js:33:14)
May 21 12:09:55 at Function.mkdirpSync [as sync] (/app/code/node_modules/mkdirp/index.js:21:7)
May 21 12:09:55 at Client.initFileStructure (/app/code/node_modules/pm2/lib/Client.js:133:25)
May 21 12:09:55 at new module.exports (/app/code/node_modules/pm2/lib/Client.js:38:8)
May 21 12:09:55 at new API (/app/code/node_modules/pm2/lib/API.js:107:19)

this does not prevent the app from working properly...

@girish Thanks!

Hello,
I'm encountering an issue with my web app hosted on a Surfer app. When trying to access or download a file located at /.well-known/assetlinks.json, I consistently get a 500 Internal Server Error with the message: {"status":"Internal Server Error","message":"unsupported type"}.

Here's the relevant error from my logs:

May 16 10:50:37 HttpError: unsupported type
May 16 10:50:37 at file:///app/code/src/files.js:105:50
May 16 10:50:37 at FSReqCallback.oncomplete (node:fs:199:5) {
May 16 10:50:37 status: 500,
May 16 10:50:37 internalError: null,
May 16 10:50:37 details: null
May 16 10:50:37 }
May 16 10:50:37 GET /.well-known/assetlinks.json 500 2.449 ms - 63

The problem seems to be specifically with the .well-known hidden folder. When I put this same file in the public folder or any other subfolder, it works fine, but anything inside the .well-known folder returns this error.

thanks

Thanks to the Cloudron team who solved the problem very quickly on a Sunday. I had been struggling with the server for more than 4 hours, and they fixed the issue in 30 minutes!

i pretty much have the same problem and logs, an dredis is reporting up and healthy ...
tried to debug it myself but can't get apps to come back online.
i'm reaching support@cloudron.io but it's Sunday.

@girish Done !

@rosano posted a simple tutorial for installing custom apps without docker : https://forum.cloudron.io/topic/11349/install-custom-app-via-private-registry-and-cloudron-build

i have done a Cloudron package at https://git.cloudron.io/nils/pocketbase if some adventurous Cloudroneers want to test it. Packaging it is pretty easy but i'm not sure to keep it updated if it does not fit my needs.
Also i may be more interested to fork the base project to support Postgresql because SQLite... i don't know... it feels weak to me.

i have to test it in production so i've done it here : https://git.cloudron.io/nils/pocketbase
i may improve this package ,handling Cloudron user management and email configuration if people or i find interest in it .

I'm sorry for awakening an old thread, but as this subject came up first in my Google search, I thought it would be wise to share a proper solution regarding the unfiltered_html setting in Cloudron's WordPress managed app.

In the WordPress managed app, the unfiltered_html capability is configured in the wp-config.php file :

define('DISALLOW_UNFILTERED_HTML', true);

to revert this you can just change this line to the following one:

define('DISALLOW_UNFILTERED_HTML', false);

The reason WordPress managed on Cloudron could be a better choice for some use cases, particularly from a security standpoint, is noteworthy. In the managed version, most of the WordPress files are on an immutable partition, meaning they cannot be altered. This greatly lowers the risk of security issues caused by unauthorized changes to the files.
Also, as the WordPress core files are part of the WordPress cloudron app's, they are not included in the Cloudron's backups, making the backups lighter and quicker since only plugins data and customizations are backed up, not the entire WordPress core.

as the error suggest , i have deleted the 'directory_server_config' row in the settings table and all seems back to normal.
detailed resolution steps for references :

1. connect to the server via SSH
2. cd to /home/yellowtent/box/setup
3. run the start.sh script as root

• if it raise the error : AssertionError [ERR_ASSERTION]: ifError got unwanted exception: Duplicate entry 'directory_server_config' for key 'settings.PRIMARY' then you can solve it with the following :

4. run mysql --password=password --database=box
5. just to be safe run select * from settings where name='directory_server_config'; and backup the result somwhere..;
6. run delete from settings where name='directory_server_config';
7. then exit
8. re-run the start script as root ./start.sh and the error should be gone

my cloudron has updated last night and since the dashboard is unresponsive, also the mail service is down .
here are the box logs :

q2023-12-04T08:25:17.553Z box:server ==========================================
2023-12-04T08:25:17.553Z box:server            Cloudron 7.6.1  
2023-12-04T08:25:17.553Z box:server ==========================================
2023-12-04T08:25:17.554Z box:platform initializing platform
2023-12-04T08:25:17.606Z box:tasks stopAllTasks: stopping all tasks
2023-12-04T08:25:17.607Z box:shell stopTask spawn: /usr/bin/sudo -S /home/yellowtent/box/src/scripts/stoptask.sh all
2023-12-04T08:25:17.639Z box:shell stopTask (stdout): All tasks stopped

2023-12-04T08:25:17.662Z box:reverseproxy writeDashboardConfig: writing dashboard config for 3es.io
2023-12-04T08:25:17.688Z box:shell reload spawn: /usr/bin/sudo -S /home/yellowtent/box/src/scripts/restartservice.sh nginx
Error: Error starting server: {"name":"BoxError","reason":"Database Error","details":{},"message":"ER_BAD_FIELD_ERROR: Unknown column 'type' in 'field list'","nestedError":{"code":"ER_BAD_FIELD_ERROR","errno":1054,"sqlMessage":"Unknown column 'type' in 'field list'","sqlState":"42S22","index":0,"sql":"INSERT INTO notifications (type, title, message, acknowledged, eventId) VALUES ('cloudronUpdated', 'Cloudron updated to v7.6.1', 'Cloudron was updated from v7.5.2 to v7.6.1.\\n\\nChangelog:\\n* Cleanup backup validation mount point\\n* dashboard: remove nginx config of old domain when domain changed\\n* Show disk consumption of docker volumes for /run and /tmp of apps separately\\n* dns: add dnsimple automation\\n* roles: admin role can access branding and networking\\n* dns: add ovh backend\\n\\n', false, '263e1e2a-9094-4ee5-80e7-4bcee41e8fde')"},"code":"ER_BAD_FIELD_ERROR","sqlMessage":"Unknown column 'type' in 'field list'"}
    at main (/home/yellowtent/box/box.js:48:41)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

i have rebooted and tried to run the /home/yellowtent/box/setup/start.sh script as root but it failed with this error :

./start.sh
2023-12-04T08:29:56 ==> start: Cloudron Start
media:x:500:
2023-12-04T08:29:56 ==> start: Configuring docker
Synchronizing state of apparmor.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable apparmor
2023-12-04T08:29:59 ==> start: Ensuring directories
2023-12-04T08:29:59 ==> start: Configuring journald
2023-12-04T08:30:00 ==> start: Setting up unbound
2023-12-04T08:30:00 ==> start: Adding systemd services
Synchronizing state of unbound.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable unbound
Synchronizing state of cron.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable cron
2023-12-04T08:30:13 ==> start: Configuring sudoers
2023-12-04T08:30:13 ==> start: Configuring collectd
2023-12-04T08:30:13 ==> start: Configuring sysctl
2023-12-04T08:30:13 ==> start: Configuring logrotate
2023-12-04T08:30:13 ==> start: Adding motd message for admins
2023-12-04T08:30:13 ==> start: Configuring nginx
2023-12-04T08:30:13 ==> start: Starting mysql
mysqladmin: [Warning] Using a password on the command line interface can be insecure.
Warning: Since password will be sent to server in plain text, use ssl connection to ensure password safety.
mysql: [Warning] Using a password on the command line interface can be insecure.
mysql: [Warning] Using a password on the command line interface can be insecure.
2023-12-04T08:30:13 ==> start: Migrating data
Ignoring invalid configuration option passed to Connection: driver. This is currently a warning, but in future versions of MySQL2, an error will be thrown if you pass an invalid configuration option to a Connection
[ERROR] AssertionError [ERR_ASSERTION]: ifError got unwanted exception: Duplicate entry 'directory_server_config' for key 'settings.PRIMARY'
    at /home/yellowtent/box/node_modules/db-migrate/lib/commands/on-complete.js:15:14
    at tryCatcher (/home/yellowtent/box/node_modules/bluebird/js/release/util.js:16:23)
    at Promise.successAdapter (/home/yellowtent/box/node_modules/bluebird/js/release/nodeify.js:22:30)
    at Promise._settlePromise (/home/yellowtent/box/node_modules/bluebird/js/release/promise.js:601:21)
    at Promise._settlePromiseCtx (/home/yellowtent/box/node_modules/bluebird/js/release/promise.js:641:10)
    at _drainQueueStep (/home/yellowtent/box/node_modules/bluebird/js/release/async.js:97:12)
    at _drainQueue (/home/yellowtent/box/node_modules/bluebird/js/release/async.js:86:9)
    at Async._drainQueues (/home/yellowtent/box/node_modules/bluebird/js/release/async.js:102:5)
    at Async.drainQueues [as _onImmediate] (/home/yellowtent/box/node_modules/bluebird/js/release/async.js:15:14)
    at process.processImmediate (node:internal/timers:476:21)
    at Packet.asError (/home/yellowtent/box/node_modules/mysql2/lib/packets/packet.js:728:17)
    at Query.execute (/home/yellowtent/box/node_modules/mysql2/lib/commands/command.js:29:26)
    at Connection.handlePacket (/home/yellowtent/box/node_modules/mysql2/lib/connection.js:456:32)
    at PacketParser.onPacket (/home/yellowtent/box/node_modules/mysql2/lib/connection.js:85:12)
    at PacketParser.executeStart (/home/yellowtent/box/node_modules/mysql2/lib/packet_parser.js:75:16)
    at Socket.<anonymous> (/home/yellowtent/box/node_modules/mysql2/lib/connection.js:92:25)
    at Socket.emit (node:events:513:28)
    at addChunk (node:internal/streams/readable:324:12)
    at readableAddChunk (node:internal/streams/readable:297:9)
    at Readable.push (node:internal/streams/readable:234:10)
    at TCP.onStreamRead (node:internal/stream_base_commons:190:23)
2023-12-04T08:30:14 ==> start: DB migration failed

from what i can tell all other services seems ok since i have acces to most of the installed apps.

@jdaviescoates actually it should work with any cloudron apps that use the mysql addon (and no other database addons)

Just wanted to share a bash script that handle the migration of a wordpress app
You must have a rsync backup of the app on Minio to use this script
Since i've made this script because the Cloudron restore thing don't work for many of my wordpress instances the script connect to the Minio api to download a backup, then it creates an app on the destination cloudron and handle the files and database import.

i've made it available on the Cloudron Gitlab here : https://git.cloudron.io/nils/wordpress-migration-from-minio
( @cloudronTeam tell me if you want me to host it elsewhere).

this script could be useful if you get the following error when cloning / restoring or migrating an app:
External Error: Error loading fsmetadata.json:ENOENT: no such file or directory, open '/home/yellowtent/appsdata/66b1a0bd-.../fsmetadata.json'

@girish App A is up and running
i have made some more test today and results are mitigated...
on Cloudron 1 the problème seem to be gone, i can't explain why...

On Cloudron 2 the errors only occure on wordpress(unmanaged) apps.

@girish to clarify the situation:

Since I changed the configuration of the backups I can no longer clone the apps that were installed before the change.

example :
"app A" is installed since January 1st 2020
"app B" is installed since January 1st 2024
I changed the configuration on January 1st 2022

I can clone "App B" from its backup of January 2nd 2024.
I can't clone "App A" from its backup of January 2nd 2024, I have the error mentioned earlier.

I'm only talking about cloning because I don't want to try to restore "App A" for fear of being stuck with the same error

@girish yes , my problème is that cloning any apps installed before the new backup configuration fail with the error reported earlier, even from new backups stored on the currently configured minio.
the same happen on my two cloudrin servers

@girish i have not migrated the content from the old Minio.
i have just set up a new Minio then i have reconfigured the Cloudron to backup to the new Minio.
restoring/cloning apps created after this works but doesn't on older ones.

i migrated my backup that was running on a Minio instance on another Minio instance.
Since I've done this it's impossible for me to restore/clone apps. I have this error:

External Error: Error loading fsmetadata.json:ENOENT: no such file or directory, open '/home/yellowtent/appsdata/66b1a0bd-7a9e-497b-bba8-c5772ed40fc4/fsmetadata.json'

I tried trick found elsewhere on the forum that consisted changed the backup method ( rsync to tarball then save then back to rsync then cleanup backups) but nothing does it.

thanks