Cloudron Forum

@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?

Hello @djxx You can find that file in the systemd mount file for the Cloudron backup. systemctl status mnt-cloudronbackup.mount ● mnt-cloudronbackup.mount - cloudronbackup Loaded: loaded (/etc/systemd/system/mnt-cloudronbackup.mount; enabled; preset: enabled) Active: active (mounted) since Sat 2025-05-17 07:04:02 UTC; 2 weeks 1 day ago Where: /mnt/cloudronbackup What: REDACTED@REDACTED.your-storagebox.de:/home Tasks: 11 (limit: 9212) Memory: 9.9M (peak: 18.1M swap: 2.5M swap peak: 11.1M) CPU: 25min 37.199s CGroup: /system.slice/mnt-cloudronbackup.mount ├─ 905 /sbin/mount.fuse.sshfs REDACTED@REDACTED.your-storagebox.de:/home /mnt/cloudronbackup -o rw,allow_oth> └─9487 ssh -x -a -oClearAllForwardings=yes -oport=23 -oIdentityFile=/home/yellowtent/platformdata/sshfs/id> Notice: journal has been rotated since unit was started, output may be incomplete. So the file in question would be: /etc/systemd/system/mnt-cloudronbackup.mount

Yes, I've been doing this for years, you just have to make /app/data friendly enough for apps to find what they need. This generally involves setting a few env variables: HOME PATH (including NODE_PATH avoiding npm i -g) LD_LIBRARY_PATH (less common) other app specific ENVs All of these changes do not affect the running app since it's already running with its own ENVs. So these are great for additional services. Nice work @djxx

@girish Thanks for clarifying. Now I'm on to fixing other bugs!

@djxx ha ha, sorry I misunderstood The bounce message is sent from Cloudron for undeliverable messages. You can send randomaddress@domain.com and you will get that bounce back message. Going back to your original problem, if gmail is blocking you , the only way to unblock is to wait it out. From your original mail, you are getting blocked at IP level. This means that gmail most likely blocked your entire VPS provider range. You have to set up a relay to get out of this situation - https://docs.cloudron.io/email/#relay-outbound-mails . If your mail is only getting to spam (instead of IP blocked), then usually you have to just "wait" it out. From many years ago, we just sent email from cloudron.io to various gmail friends and asked the to mark as not-spam. After that, it started going through. But gmail is a black box, who knows what they do now.

Such posts are totally fine . Even if you migrate the other way around. I think all posts around Cloudron and selfhosting are welcome as long as discussion/posts are civil.

@timconsidine Yes, this is what I run today and it has worked really, really well ... integrates nicely with Gitlab. But the deprecation the Gitlab folks have in mind for 3rd party registries is a worry (https://docs.gitlab.com/administration/packages/container_registry/#use-an-external-container-registry-with-gitlab-as-an-auth-endpoint). There's talk about them doing a hard deprecation which I'm taking to mean would stop it working completely rather than just being unsupported as today

@djxx oh wow, thanks for the detailed write up! Hopefully it's useful for other people migrating as well. I will add a link to your report from our docs.

@nebulon Yes - I was getting confused about the WebDAV API keys, what user name as needed, etc. The thing that helped the most was clicking on the SFTP dialog for the app, which makes it very clear what the login information is. Clicking on SFTP for the Surfer app shows: [image: 1723582196179-f04ce061-ff35-4938-8219-ff57e38b8783-image.png] Thanks for your help! One more app configured and migrated

Right as I typed that, I realized that there is the "send" icon next to it, which when clicking shows the link to set up the user's account. I realized that I could confirm the user's account on my own. I can initialize the account with the password I want, and then I also see the key icon you're referring to and am able to reset it that way. Thank you for your help!

@joseph Thanks for this! I was trying to wrap it up last night so I decided to just reset all the users passwords to a known password, and then send them a password reset link to change it to their old password on their own. I will definitely keep the group approach in mind next time I'm migrating to Cloudron - but my next server likely won't migrate until XMPP gets some love ( https://forum.cloudron.io/topic/10465/xmpp-server-prosody/26?_=1723504540984 )

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: https://prosody.im/doc/migrator https://prosody.im/doc/storage   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"; }

@djxx I wouldn't say running a CI runner a "little thing" But anyway, it's up to you if you feel comfortable and are aware of the repercussions of installing things give access to all your containers. I have no idea about sysbox, never tried it.

@djxx https://github.com/processone/ejabberd/discussions/4095#discussioncomment-7251934