@Mamouti if you need (smallish) changes to the packages, feel free to submit MRs . All the packages are at https://git.cloudron.io/packages/

Thank you. I will try cloudron-support --troubleshoot next time.

@jpavlovski I confirm I had again three days ago

@joseph Here are some excerpts from the log around the time I noticed the problem ("XXXXX" were manually added): 025-03-31T14:41:08.552Z box:server ========================================== 2025-03-31T14:41:08.553Z box:server Cloudron 8.3.1 2025-03-31T14:41:08.553Z box:server ========================================== 2025-03-31T14:41:08.554Z box:platform initialize: start platform 2025-03-31T14:41:08.889Z box:tasks stopAllTasks: stopping all tasks 2025-03-31T14:41:08.889Z box:shell tasks /usr/bin/sudo -S /home/yellowtent/box/src/scripts/stoptask.sh all 2025-03-31T14:41:09.138Z box:shell All tasks stopped 2025-03-31T14:41:09.443Z box:locks releaseAll: all locks released 2025-03-31T14:41:09.486Z box:reverseproxy writeDashboardConfig: writing dashboard config for sebastienvigneau.xyz 2025-03-31T14:41:09.645Z box:shell reverseproxy: openssl x509 -in /home/yellowtent/platformdata/nginx/cert/my.sebastienvigneau.xyz.cert -noout -ocsp_uri 2025-03-31T14:41:09.757Z box:shell reverseproxy /usr/bin/sudo -S /home/yellowtent/box/src/scripts/restartservice.sh nginx 2025-03-31T14:41:12.464Z box:platform onActivated: starting post activation services 2025-03-31T14:41:12.464Z box:platform startInfra: checking infrastructure 2025-03-31T14:41:12.569Z box:platform startInfra: updating infrastructure from 49.8.0 to 49.8.0 2025-03-31T14:41:12.570Z box:platform markApps: changedAddons: ["mysql","postgresql","mongodb","redis"] 2025-03-31T14:41:12.736Z box:services startServices: existing infra. incremental service create ["start","startTurn","startMysql","startPostgresql","startMongodb","startRedis","startGraphite","start"] 2025-03-31T14:41:12.736Z box:mailserver startMail: starting 2025-03-31T14:41:12.739Z box:mailserver restart: restarting mail container with mailFqdn:my.sebastienvigneau.xyz mailDomain:sebastienvigneau.xyz 2025-03-31T14:41:12.882Z box:locks write: current locks: {"mail_restart":null} 2025-03-31T14:41:12.882Z box:locks acquire: mail_restart 2025-03-31T14:41:13.100Z box:mailserver configureMail: stopping and deleting previous mail container 2025-03-31T14:42:42.033Z box:mailserver createMailConfig: generating mail config with my.sebastienvigneau.xyz 2025-03-31T14:42:42.068Z box:mailserver configureMail: starting mail container 2025-03-31T14:42:42.068Z box:shell mailserver: /bin/bash -c docker run --restart=always -d --name=mail --net cloudron --net-alias mail --log-driver syslog --log-opt syslog-address=unix:///home/yellowtent/platformdata/logs/syslog.sock --log-opt syslog-format=rfc5424 --log-opt tag=mail -m 536870912 --memory-swap -1 --dns 172.18.0.1 --dns-search=. --ip 172.18.30.4 -e CLOUDRON_MAIL_TOKEN=XXXXX -e CLOUDRON_RELAY_TOKEN=XXXXX -e LOGLEVEL=info -v /home/yellowtent/boxdata/mail:/app/data -v /home/yellowtent/platformdata/addons/mail:/etc/mail:ro -p 587:2587 -p 993:9993 -p 4190:4190 -p 25:2587 -p 465:2465 -p 995:9995 --label isCloudronManaged=true --read-only -v /run -v /tmp registry.docker.com/cloudron/mail:3.15.0@sha256:c93b5a83fc4e775bda4e05010bd19e5a658936e7a09cf7e51281e3696fde4536 2025-03-31T14:43:33.399Z box:locks write: current locks: {} 2025-03-31T14:43:33.399Z box:locks release: mail_restart 2025-03-31T14:43:33.399Z box:docker deleteImage: removing registry.docker.com/cloudron/mail:3.14.9@sha256:c51a2ee20b2087e208084a9115cc6a525e3b3b227b52d8cfdac2d98a6409672e 2025-03-31T14:43:33.405Z box:services startTurn: stopping and deleting previous turn container 2025-03-31T14:44:04.243Z box:services startTurn: starting turn container 2025-03-31T14:44:04.243Z box:shell services: /bin/bash -c docker run --restart=always -d --name=turn --hostname turn --net host --log-driver syslog --log-opt syslog-address=unix:///home/yellowtent/platformdata/logs/syslog.sock --log-opt syslog-format=rfc5424 --log-opt tag=turn -m 268435456 --memory-swap -1 -e CLOUDRON_TURN_SECRET=XXXXX -e CLOUDRON_REALM=my.sebastienvigneau.xyz --label isCloudronManaged=true --read-only -v /tmp -v /run registry.docker.com/cloudron/turn:1.8.0@sha256:cdbe83c3c83b8f25de3a5814b121eb941b457dca7127d2e6ff446c7a0cfa1570 2025-03-31T14:44:15.397Z box:docker deleteImage: removing registry.docker.com/cloudron/turn:1.7.2@sha256:9ed8da613c1edc5cb8700657cf6e49f0f285b446222a8f459f80919945352f6d 2025-03-31T14:44:15.400Z box:services startMysql: stopping and deleting previous mysql container 2025-03-31T14:44:29.585Z box:services startMysql: starting mysql container 2025-03-31T14:44:29.585Z box:shell services: /bin/bash -c docker run --restart=always -d --name=mysql --hostname mysql --net cloudron --net-alias mysql --log-driver syslog --log-opt syslog-address=unix:///home/yellowtent/platformdata/logs/syslog.sock --log-opt syslog-format=rfc5424 --log-opt tag=mysql --ip 172.18.30.1 -e CLOUDRON_MYSQL_TOKEN=XXXXX -e CLOUDRON_MYSQL_ROOT_HOST=172.18.0.1 -e CLOUDRON_MYSQL_ROOT_PASSWORD=XXXXX -v /home/yellowtent/platformdata/mysql:/var/lib/mysql --label isCloudronManaged=true --cap-add SYS_NICE --read-only -v /tmp -v /run registry.docker.com/cloudron/mysql:3.5.0@sha256:969ea5b2f91861940ca6309c7676c52e479d2a864ba3aabd08a4266799707280 2025-03-31T14:44:36.436Z box:services Waiting for mysql 2025-03-31T14:44:36.442Z box:services Attempt 1 failed. Will retry: Network error waiting for mysql: connect ECONNREFUSED 172.18.30.1:3000 2025-03-31T14:44:51.455Z box:services Attempt 2 failed. Will retry: Network error waiting for mysql: connect ECONNREFUSED 172.18.30.1:3000 2025-03-31T14:45:06.732Z box:services Attempt 3 failed. Will retry: Error waiting for mysql. Status code: 200 message: connect ECONNREFUSED 127.0.0.1:3306 2025-03-31T14:45:22.063Z box:docker deleteImage: removing registry.docker.com/cloudron/mysql:3.4.3@sha256:8934c5ddcd69f24740d9a38f0de2937e47240238f3b8f5c482862eeccc5a21d2 2025-03-31T14:45:26.965Z box:services startPostgresql: postgresql will be upgraded 2025-03-31T14:45:26.965Z box:services exportDatabase: Exporting postgresql 2025-03-31T14:45:26.972Z box:services exportDatabase: Exporting addon postgresql of app 1bd225ff-a0e5-4f80-866f-99bd40115530 2025-03-31T14:45:26.973Z box:services Backing up postgresql 2025-03-31T14:45:26.976Z box:services exportDatabase: Error exporting postgresql of app 1bd225ff-a0e5-4f80-866f-99bd40115530. BoxError: Could not pipe http://172.18.30.2:3000/databases/db1bd225ffa0e54f80866f99bd40115530/backup?access_token=XXXXX to /home/yellowtent/appsdata/1bd225ff-a0e5-4f80-866f-99bd40115530/postgresqldump: connect ECONNREFUSED 172.18.30.2:3000 at ClientRequest.<anonymous> (/home/yellowtent/box/src/services.js:1350:47) at ClientRequest.emit (node:events:519:28) at emitErrorEvent (node:_http_client:101:11) at Socket.socketErrorListener (node:_http_client:504:5) at Socket.emit (node:events:519:28) at emitErrorNT (node:internal/streams/destroy:169:8) at emitErrorCloseNT (node:internal/streams/destroy:128:3) at process.processTicksAndRejections (node:internal/process/task_queues:82:21) { reason: 'Network Error', details: {} } 2025-03-31T14:45:26.976Z box:platform startInfra: Failed to start services. retry=false (attempt 0): Could not pipe http://172.18.30.2:3000/databases/db1bd225ffa0e54f80866f99bd40115530/backup?access_token=XXXXX to /home/yellowtent/appsdata/1bd225ff-a0e5-4f80-866f-99bd40115530/postgresqldump: connect ECONNREFUSED 172.18.30.2:3000 2025-03-31T14:45:26.976Z box:platform BoxError: Could not pipe http://172.18.30.2:3000/databases/db1bd225ffa0e54f80866f99bd40115530/backup?access_token=XXXXX to /home/yellowtent/appsdata/1bd225ff-a0e5-4f80-866f-99bd40115530/postgresqldump: connect ECONNREFUSED 172.18.30.2:3000 at ClientRequest.<anonymous> (/home/yellowtent/box/src/services.js:1350:47) at ClientRequest.emit (node:events:519:28) at emitErrorEvent (node:_http_client:101:11) at Socket.socketErrorListener (node:_http_client:504:5) at Socket.emit (node:events:519:28) at emitErrorNT (node:internal/streams/destroy:169:8) at emitErrorCloseNT (node:internal/streams/destroy:128:3) at process.processTicksAndRejections (node:internal/process/task_queues:82:21) 2025-03-31T18:15:19.191Z box:shell system: swapon --noheadings --raw --bytes --show=type,size,used,name 2025-03-31T18:15:19.505Z box:shell services: grep -q avx /proc/cpuinfo 2025-03-31T18:15:19.608Z box:shell services: systemctl is-active nginx 2025-03-31T18:15:19.610Z box:shell services: systemctl is-active unbound 2025-03-31T18:16:37.596Z box:shell system: swapon --noheadings --raw --bytes --show=type,size,used,name 2025-03-31T18:16:40.619Z box:shell system /usr/bin/sudo -S /home/yellowtent/box/src/scripts/reboot.sh 2025-03-31T18:16:40.968Z box:box Received SIGTERM. Shutting down. 2025-03-31T18:16:40.969Z box:platform uninitializing platform 2025-03-31T18:16:40.969Z box:shell system: /usr/bin/sudo -S /home/yellowtent/box/src/scripts/reboot.sh errored BoxError: system exited with code null signal SIGTERM at ChildProcess.<anonymous> (/home/yellowtent/box/src/shell.js:137:19) at ChildProcess.emit (node:events:519:28) at ChildProcess.emit (node:domain:488:12) at ChildProcess._handle.onexit (node:internal/child_process:294:12) { reason: 'Shell Error', details: {}, code: null, signal: 'SIGTERM' } 2025-03-31T18:16:40.970Z box:system reboot: could not reboot. BoxError: system exited with code null signal SIGTERM at ChildProcess.<anonymous> (/home/yellowtent/box/src/shell.js:137:19) at ChildProcess.emit (node:events:519:28) at ChildProcess.emit (node:domain:488:12) at ChildProcess._handle.onexit (node:internal/child_process:294:12) { reason: 'Shell Error', details: {}, code: null, signal: 'SIGTERM' } 2025-03-31T18:16:40.977Z box:platform onDeactivated: stopping post activation services 2025-03-31T18:16:40.977Z box:tasks stopAllTasks: stopping all tasks 2025-03-31T18:16:40.978Z box:shell tasks /usr/bin/sudo -S /home/yellowtent/box/src/scripts/stoptask.sh all 2025-03-31T18:16:41.456Z box:shell All tasks stopped Anyway, I ended up running cloudron-support --recreate-docker, which made the apps functional again, and I am now restoring them from the backup one by one.

This support request is resolved. Should I delete this?

@thoresson said in SPF failure for IPv6 – but IPv6 is disabled on my server: @joseph No idea how, all I did was to take a break from this to cook dinner, but now it works. Probably just took a while for the changes you made to propagate

@joseph That's right! I thought that was the easiest way to increase the deliverability of emails sent from my Cloudron server. But apparently my understanding of DNS is lacking. I checked my VPS' ip address and it's not in any blacklists, so switching to the internal SMTP server.

One idea, to get more insight, you can use the following command to see which ciphers openssl would use, while you can control what it offers: openssl s_client -starttls smtp -connect my.YOURCLOUDRON.DOMAIN:587 -cipher 'ECDHE:!aNULL' -tls1_2 So ECDHE:!aNULL can be replaced with a cipher you are certain that other server supports.

I wonder if this is perhaps related to the issue being troubleshot here: https://forum.cloudron.io/post/104263

Yeah can confirm, and thanks for the help diagnosing. I wasn't given any advanced notice of the SMTP block, it was hidden in release notes somewhere. This is now unblocked.

@hakh looks like IPv6 connectivity in your server is not working. Does ping6 ipv6.api.cloudron.io work for you?

Hi, did you check this, this and this? I got the similar errors when trying to run the indexing but after a few retry it works. I tried to index email mailbox separately (by running the command inside the rebuild-index.sh for each mailbox separately) and identified which one caused the problem, then I had to open/read the problematic folders with a mail client, and then the index worked. Given this feels like another duplicate, @staff, there might be something up / to improve with how the indexing is handled.

@girish Here's what I found: https://www.qwant.com/?q=long+run+copies+via+cp+causing+oom+memory Various OOM workarounds: https://github.com/rfjakob/earlyoom https://github.com/hakavlad/nohang https://github.com/facebookincubator/oomd https://gitlab.freedesktop.org/hadess/low-memory-monitor/ https://github.com/endlessm/eos-boot-helper/tree/master/psi-monitor Understanding OOM Score adjustment: https://last9.io/blog/understanding-the-linux-oom-killer/ Possible LowFree issue: https://bugzilla.redhat.com/show_bug.cgi?id=536734 Parallel vs sequential copy: https://askubuntu.com/questions/1471139/fuse-zip-using-cp-reported-running-out-of-virtual-memory And lastly, since you use stdio as output, perhaps it fills that up somehow. If it were redirected to disk it might be different. That might also enable resuming a failed restore.

Du to high amounts of spam, we require each new user to get manually approved by us. This happens with the first post, so in your case this one. So welcome here

@BrutalBirdie Ok fixed. The Cloudron did not even show me that. I have fixed the issue now.

@avatar1024 said in Email search not working properly: What's tika? tika is this - https://tika.apache.org/ . it converts the pdf/docs attachments in emails to text to make them searchable

Flattered Thanks for the appreciation.

@nebulon here's what an AI found: Tarball Permissions The tarball contains files with ownership/permissions the process can’t replicate (e.g., root-owned files). Example: Extraction fails when tar.extract preserves original ownership. SELinux/AppArmor Security policies block filesystem operations despite correct permissions. Tar Library Behavior: The tar library (likely tar-fs) might try to preserve file permissions from the tarball. If the tarball contains files owned by root and the app runs as yellowtent, extraction fails unless permissions are ignored. Fix: Modify the code to ignore permissions: javascript const tarStream = tar.extract({ cwd: destinationPath, ignore: () => true }); Debugging Steps Check Permissions: javascript console.log('Source:', fs.statSync(sourcePath).mode.toString(8)); console.log('Dest:', fs.statSync(destinationPath).mode.toString(8)); Ensure Directory Exists: javascript if (!fs.existsSync(destinationPath)) fs.mkdirSync(destinationPath, { recursive: true }); fs.accessSync(destinationPath, fs.constants.W_OK); Add Error Logging: javascript const readStream = fs.createReadStream(sourcePath).on('error', (err) => console.error('Read:', err)); const unzipStream = zlib.createGunzip().on('error', (err) => console.error('Gunzip:', err)); const tarStream = tar.extract({ cwd: destinationPath }).on('error', (err) => console.error('Tar:', err)); Potential Fixes Ignore Tar Permissions: javascript const tarStream = tar.extract({ cwd: destinationPath, ignore: () => true }); Test with Logging: Run the modified code with error handlers. async function tarExtract(sourcePath, destinationPath) { ensureSafePath(sourcePath); ensureSafePath(destinationPath); console.log('Source:', sourcePath, fs.statSync(sourcePath)); console.log('Dest:', destinationPath, fs.existsSync(destinationPath) ? fs.statSync(destinationPath) : 'does not exist'); const readStream = fs.createReadStream(sourcePath) .on('error', (err) => console.error('Read error:', err)); const unzipStream = zlib.createGunzip() .on('error', (err) => console.error('Gunzip error:', err)); const tarStream = tar.extract({ cwd: destinationPath }) .on('error', (err) => console.error('Tar error:', err)); readStream.pipe(unzipStream).pipe(tarStream); await streamPromise(tarStream); } Conclusion The error is likely a mismatch between the Cloudron app’s user permissions and the filesystem.