Cloudron Forum

There is the following error occuring when i run

/home/yellowtent/box/setup/start.sh

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-09-26T17:40:40 ==> 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 'sftp_rsa_private_key' for key 'blobs.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-09-26T17:40:41 ==> start: DB migration failed

I am facing the situation, where a before configured and running Cloudron instance is now showing the DNS setup window (on the previous running my.xy.com dashboard site).

When I then enter the domain again and choose wildcard for certificate configuration, I see the error msg "Already activated". In the box logs I see this:

2023-09-25T12:51:47.742Z box:platform BoxError: ER_BAD_FIELD_ERROR: Unknown column 'apps.enableTurn' in 'field list'
    at Query.queryCallback (/home/yellowtent/box/src/database.js:91:38)
    at Query.<anonymous> (/home/yellowtent/box/node_modules/mysql/lib/Connection.js:526:10)
    at Query._callback (/home/yellowtent/box/node_modules/mysql/lib/Connection.js:488:16)
    at Sequence.end (/home/yellowtent/box/node_modules/mysql/lib/protocol/sequences/Sequence.js:83:24)
    at Query.ErrorPacket (/home/yellowtent/box/node_modules/mysql/lib/protocol/sequences/Query.js:92:8)
    at Protocol._parsePacket (/home/yellowtent/box/node_modules/mysql/lib/protocol/Protocol.js:291:23)
    at Parser._parsePacket (/home/yellowtent/box/node_modules/mysql/lib/protocol/Parser.js:433:10)
    at Parser.write (/home/yellowtent/box/node_modules/mysql/lib/protocol/Parser.js:43:10)
    at Protocol.write (/home/yellowtent/box/node_modules/mysql/lib/protocol/Protocol.js:38:16)
    at Socket.<anonymous> (/home/yellowtent/box/node_modules/mysql/lib/Connection.js:88:28)

This situation happened after a scheduled reboot was executed. After the reboot succeeded, I ended up like this. What might have happened? Thanks in advance!

Awesome, thanks!

I am asked by a customer to move a WP Instance to one of my Cloudrons. WP is still an older version, and I am wondering if it is possible to somehow choose the WP version on Cloudron.

(It is ofc clear to keep WP updated for a variaty of reasons, however I'd like to know.)

My Gitlab Instance is behaving very strange. If I upload a new branch foo-branch containing some changes, then switch to Repository > Branches > foo-branch, Gitlab would give me a 404.

This behaviour however varies, sometimes i manage to open a Merge Request
and once the MR is open, it would show a error message, that this branch was not found and therefore the MR is invalid.

I just updated to version and i saw these lines in the log, that might be related. Is it possible that some permissions are not set up properly and therefore the data is written into the tmp directory where it is deleted after a short time?

On the VM I checked and the permissions for the app look correct.

...
Mar 29 06:47:58 `/home/git` is not writable.
Mar 29 06:47:58 Bundler will use `/tmp/bundler20230329-142-1f8zv0b142' as your home directory temporarily.
...

Is this a known issue?

@nebulon yes, i have vaultwarden installed...

@girish I actually managed to get this running. The lower end of the section in the docs did the trick.

I had the same issue.. for me the problem was some sql query that would make the mysql server crash all the time...

2023-03-28T04:07:53.080199Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.30-0ubuntu0.20.04.2) starting as process 5166
2023-03-28T04:07:53.099776Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2023-03-28T04:07:54.219247Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
2023-03-28T04:07:54.711046Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed.
2023-03-28T04:07:54.711179Z 0 [System] [MY-013602] [Server] Channel mysql_main configured to support TLS. Encrypted connections are now supported for this channel.
2023-03-28T04:07:54.768261Z 0 [System] [MY-011323] [Server] X Plugin ready for connections. Bind-address: '::' port: 33060, socket: /var/run/mysqld/mysqlx.sock
2023-03-28T04:07:54.768378Z 0 [System] [MY-010931] [Server] /usr/sbin/mysqld: ready for connections. Version: '8.0.30-0ubuntu0.20.04.2'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu).
2023-03-28T04:07:54.829889Z 8 [ERROR] [MY-012153] [InnoDB] Trying to access page number 1664378413 in space 656, space name 602a424a87c078e5/users, which is outside the tablespace bounds. Byte offset 0, len 16384, i/o type read. If you get this error at mysqld startup, please check that your my.cnf matches the ibdata files that you have in the MySQL server.
2023-03-28T04:07:54.830033Z 8 [ERROR] [MY-012154] [InnoDB] Server exits.
2023-03-28T04:07:54.830094Z 8 [ERROR] [MY-013183] [InnoDB] Assertion failure: fil0fil.cc:7531 thread 140669377869568
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
04:07:54 UTC - mysqld got signal 6 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
Thread pointer: 0x7fefb0000fc0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 7ff0244c6d10 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0x41) [0x5563eaa8e4c1]
/usr/sbin/mysqld(print_fatal_signal(int)+0x2fb) [0x5563e992dfbb]
/usr/sbin/mysqld(my_server_abort()+0x76) [0x5563e992e106]
/usr/sbin/mysqld(my_abort()+0xe) [0x5563eaa884be]
/usr/sbin/mysqld(ut_dbg_assertion_failed(char const*, char const*, unsigned long)+0x349) [0x5563ead18f59]
/usr/sbin/mysqld(+0x26d1ae6) [0x5563eae9cae6]
/usr/sbin/mysqld(Fil_shard::do_io(IORequest const&, bool, page_id_t const&, page_size_t const&, unsigned long, unsigned long, void*, void*)+0xc12) [0x5563eaec3352]
/usr/sbin/mysqld(fil_io(IORequest const&, bool, page_id_t const&, page_size_t const&, unsigned long, unsigned long, void*, void*)+0x77) [0x5563eaec33f7]
/usr/sbin/mysqld(buf_read_page_low(dberr_t*, bool, unsigned long, unsigned long, page_id_t const&, page_size_t const&, bool)+0x171) [0x5563eadc4271]
/usr/sbin/mysqld(buf_read_page(page_id_t const&, page_size_t const&)+0x4a) [0x5563eadc48ea]
/usr/sbin/mysqld(Buf_fetch<Buf_fetch_normal>::read_page()+0x38) [0x5563ead804d8]
/usr/sbin/mysqld(Buf_fetch_normal::get(buf_block_t*&)+0x657) [0x5563ead8c017]
/usr/sbin/mysqld(Buf_fetch<Buf_fetch_normal>::single_page()+0x59) [0x5563ead8c109]
/usr/sbin/mysqld(buf_page_get_gen(page_id_t const&, page_size_t const&, unsigned long, buf_block_t*, Page_fetch, ut::Location, mtr_t*, bool)+0x233) [0x5563ead8d713]
/usr/sbin/mysqld(btr_cur_open_at_index_side(bool, dict_index_t*, unsigned long, btr_cur_t*, unsigned long, ut::Location, mtr_t*)+0x56a) [0x5563ead66c0a]
/usr/sbin/mysqld(+0x26a842b) [0x5563eae7342b]
/usr/sbin/mysqld(+0x26aa78b) [0x5563eae7578b]
/usr/sbin/mysqld(dict_stats_update(dict_table_t*, dict_stats_upd_option_t)+0xeff) [0x5563eae7991f]
/usr/sbin/mysqld(dict_stats_update(dict_table_t*, dict_stats_upd_option_t)+0xef2) [0x5563eae79912]
/usr/sbin/mysqld(ha_innobase::open(char const*, int, unsigned int, dd::Table const*)+0xa14) [0x5563eaae4fc4]
/usr/sbin/mysqld(handler::ha_open(TABLE*, char const*, int, int, dd::Table const*)+0x59) [0x5563e9a3f139]
/usr/sbin/mysqld(open_table_from_share(THD*, TABLE_SHARE*, char const*, unsigned int, unsigned int, unsigned int, TABLE*, bool, dd::Table const*)+0x1238) [0x5563e98d8728]
/usr/sbin/mysqld(open_table(THD*, TABLE_LIST*, Open_table_context*)+0x121f) [0x5563e972b9af]
/usr/sbin/mysqld(open_tables(THD*, TABLE_LIST**, unsigned int*, unsigned int, Prelocking_strategy*)+0x3c7) [0x5563e972d2d7]
/usr/sbin/mysqld(mysql_alter_table(THD*, char const*, char const*, HA_CREATE_INFO*, TABLE_LIST*, Alter_info*)+0x5fb) [0x5563e987046b]
/usr/sbin/mysqld(Sql_cmd_alter_table::execute(THD*)+0x4cc) [0x5563e9c9f5cc]
/usr/sbin/mysqld(mysql_execute_command(THD*, bool)+0xa00) [0x5563e97c0c30]
/usr/sbin/mysqld(dispatch_sql_command(THD*, Parser_state*)+0x434) [0x5563e97c5a94]
/usr/sbin/mysqld(dispatch_command(THD*, COM_DATA const*, enum_server_command)+0x1d17) [0x5563e97c7cd7]
/usr/sbin/mysqld(do_command(THD*)+0x207) [0x5563e97c8fd7]
/usr/sbin/mysqld(+0x1153e48) [0x5563e991ee48]
/usr/sbin/mysqld(+0x282ea4d) [0x5563eaff9a4d]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x9609) [0x7ff02a365609]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x43) [0x7ff0295d2293]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7fefb00ed880): ALTER TABLE users ADD COLUMN avatar_color VARCHAR(7)
Connection ID (thread ID): 8
Status: NOT_KILLED

The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

The fix from the troubleshooting guide worked fine:

docker stop mysql
mv /home/yellowtent/platformdata/mysql /home/yellowtent/platformdata/mysql-copy
mkdir /home/yellowtent/platformdata/mysql
docker restart mysql

Then I had to restore the affected applications from the backup.

@girish I also see this error on one of my cloudrons.. Will your patch soon be released in an update?

One of my Gitlab instances is configured to receive emails and also does receive most of them and processes them into issues. However, quite a good amount are missing and I have done some testing to check where the problems are.

• Cloudron mail server seems to receive and handle everything well.
• /home/gitlab/log/mail_room_json.log contains almost no errors for the period of the last several days in which i know that several mails have been missed.
• I searched the other logfiles for other related information, but could not really get something of much value.

Does anyone else experience this issue? Where can I dig deeper to find the core of the problem?

I actually found this... Could be related: https://gitlab.com/gitlab-org/gitlab/-/issues/267121

Cheers

I have realized, that several organizations are very interested in the possibility of creating their own invitation email. The possibility of adding text and attach a kind of "onboarding"-manual for all running applications would be pretty nice. It would make it really easy to do these thing automated thereafter using the API.

Yes, I did remount the shares.

@nebulon I actually run in the same issue on several instances. On some it still works however... I am using TrueNAS as the NFS server and it would be nice if i could keep using it. Any hint on where that error is coming from?

@nebulon See that point. Two use cases are:

WordPress exposes the example.com/xmlrpc.php API per default. We already had several issues where attackers used those APIs to send spam mails from our applications. To fix this issue, either you need to install a plugin that disables the API (however, dose plugins which are available for free are crapy and I dont trust them), or you just disable those requests in the nginx.conf of the application. This is what I did, but through updates those custom lines were deleted.

I would like to restrict the Synapse Admin API to certain IPs.

I would find it very useful if i could enter custom nginx rules (generally or per application), that would survive updates. Is this possible at the time beeing?

@nebulon nice! looking forward to this.. do you already know the release date?

@nebulon The instance that crashed on sunday is (and was at that time) running v7.2.5

Within the last month, I had 3 cloudron instances (running productive apps for clients) crashing, because the NFS mount could not be mounted and the root filesystem was used instead.

I find it frustrating to run into this issue so often. Mostly because I know it can happen every moment and I cant do anything about it.

How about adding a checkbox in the backup settings with the title "Skip backup if storage is not available"?

@girish I'm glad to see your efforts put in this issue. I think we are getting closer! I looked at the sip-communicator config of yunohost - as their jitsi is working on my systems and they actually set those variables.

A further indication that this is the only missing piece is this thread here...

Are there environment variables for the local and the public IPs? I would like to test this.

@girish We do have our own server farm in a data center. As host for our VMs, we use Proxmox.