Here's how I've temporarily worked around the situation:
I think there is some sort of rate limit causing issues - once you get too many items pending re-upload, it just keeps hitting the server and Cloudron starts rejecting / ignoring requests from the client, which puts it into a weird state.
@james Thanks - I did look, but it doesn't seem to be a consistent thing. Up until last week, they were all in the same camera pictures folder where most worked and some didn't. This weekend I picked another folder for auto upload, and I see about 80% of them actually uploaded but the sync didn't realize it properly so now it sees it as a conflict.
For the last few weeks I've noticed my sync isn't working properly. On the server I don't see any errors, just lots of calls in the logs. On the client, it will cycle through trying to upload all the pending items, and the majority of them will fail and get put back into the queue to retry. In the majority of the files (>90%) the file has actually synced properly, but the client doesn't think so and tries again. I'm worried some files will get missed if I ignore this issue.
Feb 08 13:48:20 IP_ADDRESS - USER [08/Feb/2026:21:48:17 +0000] "GET /index.php/core/preview?fileId=1240097&x=256&y=256&a=1&mode=cover&forceIcon=0 HTTP/1.1" 200 137849 "-" "Mozilla/5.0 (Android) Nextcloud-android/3.35.2"
Feb 08 13:48:20 IP_ADDRESS - USER [08/Feb/2026:21:48:17 +0000] "PUT /remote.php/dav/files/USER/InstantUpload/Screenshots/2025/06/Screenshot_20250620-023950.png HTTP/1.1" 201 - "-" "Mozilla/5.0 (Android) Nextcloud-android/3.35.2"
Feb 08 13:48:20 IP_ADDRESS - USER [08/Feb/2026:21:48:20 +0000] "HEAD /remote.php/dav/files/USER/InstantUpload/2026/02/Camera/PXL_20260205_001058649.jpg HTTP/1.1" 200 - "-" "Mozilla/5.0 (Android) Nextcloud-android/3.35.2"
Feb 08 13:48:20 IP_ADDRESS - USER [08/Feb/2026:21:48:20 +0000] "HEAD /remote.php/dav/files/USER/InstantUpload/Screenshots/2025/06/Screenshot_20250620-024042.png HTTP/1.1" 404 - "-" "Mozilla/5.0 (Android) Nextcloud-android/3.35.2"
Feb 08 13:48:20 IP_ADDRESS - USER [08/Feb/2026:21:48:20 +0000] "PROPFIND /remote.php/dav/files/USER/InstantUpload/2026/02/Camera/PXL_20260205_001058649.jpg HTTP/1.1" 207 1646 "-" "Mozilla/5.0 (Android) Nextcloud-android/3.35.2"
Feb 08 13:48:20 IP_ADDRESS - USER [08/Feb/2026:21:48:20 +0000] "PROPFIND /remote.php/dav/files/USER/InstantUpload/2026/02/Camera/PXL_20260205_001103777.jpg HTTP/1.1" 207 1646 "-" "Mozilla/5.0 (Android) Nextcloud-android/3.35.2"
Feb 08 13:48:20 IP_ADDRESS - USER [08/Feb/2026:21:48:20 +0000] "PROPFIND /remote.php/dav/files/USER/InstantUpload/2026/02/Camera/PXL_20260205_001103777.jpg HTTP/1.1" 207 1646 "-" "Mozilla/5.0 (Android) Nextcloud-android/3.35.2"
Feb 08 13:48:20 IP_ADDRESS - USER [08/Feb/2026:21:48:20 +0000] "PROPFIND /remote.php/dav/files/USER/InstantUpload/Screenshots/2025/06/Screenshot_20250620-023950.png HTTP/1.1" 207 1533 "-" "Mozilla/5.0 (Android) Nextcloud-android/3.35.2"
Feb 08 13:48:21 IP_ADDRESS - USER [08/Feb/2026:21:48:20 +0000] "PROPFIND /remote.php/dav/files/USER/InstantUpload/2026/02/Camera/PXL_20260205_001058649.jpg HTTP/1.1" 207 1646 "-" "Mozilla/5.0 (Android) Nextcloud-android/3.35.2"
Feb 08 13:48:21 IP_ADDRESS - USER [08/Feb/2026:21:48:21 +0000] "HEAD /remote.php/dav/files/USER/InstantUpload/2026/02/Camera/PXL_20260205_001046902.jpg HTTP/1.1" 200 - "-" "Mozilla/5.0 (Android) Nextcloud-android/3.35.2"
Feb 08 13:48:21 IP_ADDRESS - USER [08/Feb/2026:21:48:21 +0000] "HEAD /remote.php/dav/files/USER/InstantUpload/2026/02/Camera/PXL_20260205_001102555.jpg HTTP/1.1" 200 - "-" "Mozilla/5.0 (Android) Nextcloud-android/3.35.2"
Feb 08 13:48:21 IP_ADDRESS - USER [08/Feb/2026:21:48:21 +0000] "PROPFIND /remote.php/dav/files/USER/ HTTP/1.1" 207 2364 "-" "Mozilla/5.0 (Linux) mirall/4.0.1 (build 34593) (Nextcloud, linuxmint-6.17.0-14-generic ClientArchitecture: x86_64 OsArchitecture: x86_64)"
Feb 08 13:48:21 IP_ADDRESS - USER [08/Feb/2026:21:48:21 +0000] "PROPFIND /remote.php/dav/files/USER/InstantUpload HTTP/1.1" 207 1119 "-" "Mozilla/5.0 (Linux) mirall/4.0.1 (build 34593) (Nextcloud, linuxmint-6.17.0-14-generic ClientArchitecture: x86_64 OsArchitecture: x86_64)"
Feb 08 13:48:21 IP_ADDRESS - USER [08/Feb/2026:21:48:21 +0000] "PROPFIND /remote.php/dav/files/USER/InstantUpload/2026/02/Camera/PXL_20260205_001102555.jpg HTTP/1.1" 207 1646 "-" "Mozilla/5.0 (Android) Nextcloud-android/3.35.2"
Feb 08 13:48:21 IP_ADDRESS - USER [08/Feb/2026:21:48:21 +0000] "PROPFIND /remote.php/dav/files/USER/InstantUpload/2026/02/Camera/PXL_20260205_001102555.jpg HTTP/1.1" 207 1646 "-" "Mozilla/5.0 (Android) Nextcloud-android/3.35.2"
Feb 08 13:48:22 IP_ADDRESS - USER [08/Feb/2026:21:48:21 +0000] "PROPFIND /remote.php/dav/files/USER/InstantUpload/2026/02/Camera/PXL_20260205_001046902.jpg HTTP/1.1" 207 1646 "-" "Mozilla/5.0 (Android) Nextcloud-android/3.35.2"
Feb 08 13:48:22 IP_ADDRESS - USER [08/Feb/2026:21:48:22 +0000] "GET /remote.php/dav/files/USER/InstantUpload/Screenshots/2025/06/Screenshot_20250620-023950.png HTTP/1.1" 200 994782 "-" "Mozilla/5.0 (Linux) mirall/4.0.1 (build 34593) (Nextcloud, linuxmint-6.17.0-14-generic ClientArchitecture: x86_64 OsArchitecture: x86_64)"
Feb 08 13:48:22 IP_ADDRESS - USER [08/Feb/2026:21:48:22 +0000] "GET /remote.php/dav/files/USER/InstantUpload/Screenshots/2025/06/Screenshot_20250620-024042.png HTTP/1.1" 200 1111383 "-" "Mozilla/5.0 (Linux) mirall/4.0.1 (build 34593) (Nextcloud, linuxmint-6.17.0-14-generic ClientArchitecture: x86_64 OsArchitecture: x86_64)"
Feb 08 13:48:22 IP_ADDRESS - USER [08/Feb/2026:21:48:22 +0000] "HEAD /remote.php/dav/files/USER/InstantUpload/2026/02/Camera/PXL_20260204_200634502.jpg HTTP/1.1" 200 - "-" "Mozilla/5.0 (Android) Nextcloud-android/3.35.2"
Feb 08 13:48:22 IP_ADDRESS - USER [08/Feb/2026:21:48:22 +0000] "PROPFIND /remote.php/dav/files/USER/InstantUpload/2026/02/Camera/PXL_20260204_200634502.jpg HTTP/1.1" 207 1646 "-" "Mozilla/5.0 (Android) Nextcloud-android/3.35.2"
Feb 08 13:48:22 IP_ADDRESS - USER [08/Feb/2026:21:48:22 +0000] "PROPFIND /remote.php/dav/files/USER/InstantUpload/2026/02/Camera/PXL_20260204_200634502.jpg HTTP/1.1" 207 1646 "-" "Mozilla/5.0 (Android) Nextcloud-android/3.35.2"
Feb 08 13:48:22 IP_ADDRESS - USER [08/Feb/2026:21:48:22 +0000] "PROPFIND /remote.php/dav/files/USER/InstantUpload/2026/02/Camera/PXL_20260205_001046902.jpg HTTP/1.1" 207 1646 "-" "Mozilla/5.0 (Android) Nextcloud-android/3.35.2"
Feb 08 13:48:22 IP_ADDRESS - USER [08/Feb/2026:21:48:22 +0000] "PROPFIND /remote.php/dav/files/USER/InstantUpload/Screenshots HTTP/1.1" 207 760 "-" "Mozilla/5.0 (Linux) mirall/4.0.1 (build 34593) (Nextcloud, linuxmint-6.17.0-14-generic ClientArchitecture: x86_64 OsArchitecture: x86_64)"
Feb 08 13:48:22 IP_ADDRESS - USER [08/Feb/2026:21:48:22 +0000] "PROPFIND /remote.php/dav/files/USER/InstantUpload/Screenshots/2025 HTTP/1.1" 207 827 "-" "Mozilla/5.0 (Linux) mirall/4.0.1 (build 34593) (Nextcloud, linuxmint-6.17.0-14-generic ClientArchitecture: x86_64 OsArchitecture: x86_64)"
Feb 08 13:48:22 IP_ADDRESS - USER [08/Feb/2026:21:48:22 +0000] "PROPFIND /remote.php/dav/files/USER/InstantUpload/Screenshots/2025/06 HTTP/1.1" 207 2409 "-" "Mozilla/5.0 (Linux) mirall/4.0.1 (build 34593) (Nextcloud, linuxmint-6.17.0-14-generic ClientArchitecture: x86_64 OsArchitecture: x86_64)"
Feb 08 13:48:23 IP_ADDRESS - USER [08/Feb/2026:21:48:20 +0000] "GET /index.php/core/preview?fileId=1240105&x=256&y=256&a=1&mode=cover&forceIcon=0 HTTP/1.1" 200 127416 "-" "Mozilla/5.0 (Android) Nextcloud-android/3.35.2"
Feb 08 13:48:23 IP_ADDRESS - USER [08/Feb/2026:21:48:23 +0000] "HEAD /remote.php/dav/files/USER/InstantUpload/2026/02/Camera/PXL_20260206_030342845.jpg HTTP/1.1" 200 - "-" "Mozilla/5.0 (Android) Nextcloud-android/3.35.2"
Feb 08 13:48:23 IP_ADDRESS - USER [08/Feb/2026:21:48:23 +0000] "HEAD /remote.php/dav/files/USER/InstantUpload/2026/02/Camera/PXL_20260206_041450379.jpg HTTP/1.1" 200 - "-" "Mozilla/5.0 (Android) Nextcloud-android/3.35.2"
Feb 08 13:48:23 IP_ADDRESS - USER [08/Feb/2026:21:48:23 +0000] "PROPFIND /remote.php/dav/files/USER/ HTTP/1.1" 207 236 "-" "Mozilla/5.0 (Linux) mirall/4.0.1 (build 34593) (Nextcloud, linuxmint-6.17.0-14-generic ClientArchitecture: x86_64 OsArchitecture: x86_64)"
Feb 08 13:48:23 IP_ADDRESS - USER [08/Feb/2026:21:48:23 +0000] "PROPFIND /remote.php/dav/files/USER/InstantUpload/2026/02/Camera/PXL_20260206_030342845.jpg HTTP/1.1" 207 1646 "-" "Mozilla/5.0 (Android) Nextcloud-android/3.35.2"
Feb 08 13:48:23 IP_ADDRESS - USER [08/Feb/2026:21:48:23 +0000] "PROPFIND /remote.php/dav/files/USER/InstantUpload/2026/02/Camera/PXL_20260206_030342845.jpg HTTP/1.1" 207 1646 "-" "Mozilla/5.0 (Android) Nextcloud-android/3.35.2"
@murgero https://forum.cloudron.io/topic/10465/xmpp-server-prosody/44?_=1769150280326 This is the best place to look. I've pushed a repo, I've made a docker image, and I've listed the steps I followed to set it up on my own server. It's been running for over 8 months now and I haven't had issues, other than the workarounds I have to do for Cloudron packaging limitations.
At this point, I don't think the issue is having something that can be packaged. I've already packaged Prosody and it's working fine on my Cloudron. The problem is all the "hacky" things I had to do to make it work that aren't currently compatible with how packaging works - and Snikket will need to do some of those same things. So, our issue is still getting enough attention from the Cloudron team to get XMPP over the finish line.
@robi said in Snikket Server - Your own messaging server in a box:
Maybe it's a simple thing to adjust in the code and have a fork.
Then there is the maintenance issue.
Yes, the maintenance would be quite an issue. I guess Snikket will put 0 effort into not breaking customizations they told people not to make in the first place.
Prosody (and ejabberd) take care to be backwards compatible with older configurations, and follow a well-documented deprecation process when they're going to make breaking changes.
@jdaviescoates What it requires is that your username matches the TLD it is deployed to, which means it needs to be installed as the "root" application on that domain. This is incompatible with Cloudron, and frankly with how many organizations operate. It's very common to have XMPP installed somewhere like xmpp.domain.com , and the protocol supports configuration to use the TLD for accounts. This is one of the areas where Snikket is firmly standing by "it should be so simple and require no configuration" - so either you install it at the root or you live with ugly usernames like user@xmpp.domain.com.
I don't think it's worth the time to customize something that doesn't want to be customized - but rather use something that is meant to be configured and come up with sane defaults that fit Cloudron. That's what I've tried to do with my Prosody packaging.
Thanks for the upvote! I'm biased, but I think Prosody is the better choice. Snikket has too many things they do not (and possibly never will) support. The #1 reason I didn't package Snikket is not being able to use my TLD for accounts. It's a common convention to use user@domain.com for both e-mail and XMPP, but Snikket doesn't support this. The #2 reason is SSO - Snikket doesn't support it but SSO is one of my favorite features of most Cloudron apps.
Yes - you're right it's "storage". I have been meaning to try the rsync instead of zip, but it does warn that it's not a good idea for lots of files. I'll give it a try. Thanks!
@nebulon Thanks for checking! The UI change did take effect, and I do see a reduction of backup size - but it's not down to 1x the size of the backup. It's still 2x the size of the backup.
Inside the remote storage folder, I see:
It looks like the latest backup also has a copy in "storage", which is still resulting in 2x the backup space for each snapshot being taken - because each day "storage" will change, and there will be a new folder added.
@james Thanks! This was helpful. I made this change. Looking forward to the next sync so I can see if the data has been cut in half.
@girish Great! Can you give an example of how, or point me to the documentation?
Using Cloudron version 9, under Configure Backup Schedule & Retention is it possible to get an option for 1 day?
I store my backups on a ZFS pool, so I automatically get daily, weekly, and monthly snapshots of my data. Having this as 2 days causes me to spend 2x the storage space (and bandwidth) on backups.
@james Thanks for the quick reply. I didn't change any ports manually. Could it be that this and another application are conflicting and it's not being detected?
I'll run this lsof command next time it happens to see if I can identify the culprit.
MiroTalk SFU regularly gets stuck during the automatic update process:
Docker Error: (HTTP code 500) server error - failed to set up container networking: driver failed programming external connectivity on endpoint a877975d-38be-4088-bc92-e0d7a486a818 (2e5adaa635a95bd65ca0f290712065d444528e3420c49f2f88323b40c62caaa5): failed to bind host port for 0.0.0.0:40014:172.18.16.130:40014/tcp: address already in use
Not sure. It happens during updates though.
I've stopped the app, tried to retry the upgrade, retry the configure task. Sometimes it works after a few tries, other times I have to restart the server first.
Hetzner
vServer
4 Core "AMD EPYC-Milan Processor"
16.37 GB RAM & 4.29 GB Swap
9.0.15
24.04
cloudron-support --troubleshootLinux: 6.8.0-88-generic Ubuntu: noble 24.04 Execution environment: kvm Processor: AMD EPYC-Milan Processor BIOS NotSpecified CPU @ 2.0GHz x 4 RAM: 15989992KB Disk: /dev/sda1 44G [OK] node version is correct [OK] IPv6 is enabled in kernel. No public IPv6 address [OK] docker is running [OK] docker version is correct [OK] MySQL is running [OK] nginx is running [OK] dashboard cert is valid [OK] dashboard is reachable via loopback [OK] No pending database migrations [OK] Service 'mysql' is running and healthy [OK] Service 'postgresql' is running and healthy [OK] Service 'mongodb' is running and healthy [OK] Service 'mail' is running and healthy [OK] Service 'graphite' is running and healthy [OK] Service 'sftp' is running and healthy [OK] box v9.0.15 is running [OK] netplan is good [OK] DNS is resolving via systemd-resolved [OK] Dashboard is reachable via domain name [WARN] Domain domain.com expiry check skipped because whois does not have this information [OK] unbound is running
@nebulon - Congrats on the release of version 9! One of my servers just updated and the new UI looks slick. When will we get to see a slick new XMPP app in the store? 
@james said in sshfs backup duplicates network traffic?:
So, sshfs tries to issue a remote copy command but falls back to sshfs based copy if it fails for some reason.
What is your provider for sshfs? Most people here use Hetzner Storage Boxes.
I'm my own provider 
I'm just using a standard SSH install on proxmox, and the files are stored on a ZFS cluster. I don't know of anything that would stop the copy command from working; what can I do to check / troubleshoot this?
I am configuring my backup to use sshfs and noticed this while it was running:
Copying /mnt/cloudronbackup/snapshot/mail.tar.gz to /mnt/cloudronbackup/2025-07-27-215345-102/mail_v8.3.2.tar.gz
On the remote server I can see the snapshot and timestamped directory (e.g. 2025-07-27-215345-102) while the backup is running.
Based on the network traffic, it seems that while it is moving each file from snapshot to the timestamped directory, it is literally using copy, which means the file has to make another round trip. If I'm not mistaken, this means the network usage for this backup will be 3x the size of the file.
It seems like this is happening:
snapshot folderWouldn't it be much more efficient (and faster) to issue a mv command to move the file rather than have a round trip?
Also, it seems like another side effect is the snapshot folder keeps the files there until the next run - requiring 2x the space for the backup.
@nebulon Can you tell me how / where to edit this so it uses the options -o direct_io,compression=no? And if it's safe to do so, and how long the change will persist?
I'm happy to say that I've moved my XMPP server from NethServer to Cloudron. While this is probably not a common move, I am sharing some notes here in case it helps someone else. Also, perhaps this'll cause Cloudron to show up in a few more searches.
Install XMPP on Cloudron using the steps above. A bit manual for now!
Dump your ejabberd data (that's the XMPP server NethServer uses) with this command:
/opt/ejabberd-20.04/bin/ejabberdctl --config-dir /etc/ejabberd dump /etc/ejabberd/xmpp_dump.txt
Download this dump file locally
For ease, clone the source for prosody to your local computer so you can utilize the migration tools and not install needless packages on Cloudron. You'll need to run ./configure and ./make - but you don't need to actually install it.
Don't be a Lua noob. I spent a while struggling to get my Lua environment setup, and thought I needed to run the tools like lua ejabberd2prosody.lua but got lots of errors about dependencies missing. Once I figured out you need to execute it directly like ./ejabberd2prosody.lua things worked fine.
run the ejabberd2prosody.lua script on your xmpp_dump.txt file:
./tools/ejabberd2prosody.lua ~/Desktop/xmpp_migrate/xmpp_dump.txt
Create a migrator configuration (or use the one I've pasted below). It basically takes everything from the file data format and puts it into the sqlite format, since that's how the Cloudron prosody is configured. Docs:
Run the migrator script:
./tools/migration/prosody-migrator.lua --config=./migrator.cfg.lua prosody_files database
Turn off your Cloudron XMPP app
Copy the resulting prosody.sqlite file into your Cloudron XMPP's /app/data folder. It will be in the /data folder under your local prosody directory.
Turn on your Cloudron XMPP app
Your bookmarks, rosters, etc. will now be transferred to your new server! This doesn't appear to move archive messages (mod_mam). Probably because most prosody servers aren't configured to store these permanently so they don't bother migrating them.
I only noticed one issue while migrating. When I first ran the migrator script it gave me errors about topics being empty on some MUCs. I thought I was being smart and edited the code to handle the blanks. This caused me to be unable to join the MUCs on Prosody on certain XMPP clients because Prosody expects there to be a Topic for every MUC.
Once I manually adjusted the MUC topics to be non-empty, the other clients started working fine.
Another almost-issue is that Gajim needed to be restarted a few times to start using OMEMO properly. I think the other MUC issues may have thrown it into an error state.
prosody_files {
hosts = {
-- each VirtualHost to be migrated must be represented
["domain.com"] = {
"accounts";
"account_details";
"account_flags";
"account_roles";
"accounts_cleanup";
"auth_tokens";
"invite_token";
"roster";
"vcard";
"vcard_muc";
"private";
"blocklist";
"privacy";
"archive";
"archive_cleanup";
"archive_prefs";
"muc_log";
"muc_log_cleanup";
"persistent";
"config";
"state";
"cloud_notify";
"cron";
"offline";
"pubsub_nodes";
"pubsub_data";
"pep";
"pep_data";
"skeletons";
"smacks_h";
"tombstones";
"upload_stats";
"uploads";
};
["conference.domain.com"] = {
"accounts";
"account_details";
"account_flags";
"account_roles";
"accounts_cleanup";
"auth_tokens";
"invite_token";
"roster";
"vcard";
"vcard_muc";
"private";
"blocklist";
"privacy";
"archive";
"archive_cleanup";
"archive_prefs";
"muc_log";
"muc_log_cleanup";
"persistent";
"config";
"state";
"cloud_notify";
"cron";
"offline";
"pubsub_nodes";
"pubsub_data";
"pep";
"pep_data";
"skeletons";
"smacks_h";
"tombstones";
"upload_stats";
"uploads";
};
};
type = "internal"; -- the default file based backend
path = "/home/user/code/prosody-build/prosody-0.12.4/data/";
}
database {
-- The migration target does not need 'hosts'
type = "sql";
driver = "SQLite3";
database = "prosody.sqlite";
}