Cloudron Forum

@nebulon I understand, this makes sense.

Any other step I can take to help you debug the underlying problem with the new version ?

Also, I can confirm that a rollback to v1.1.0 fixes the problem for me. I am disabling auto updates for now

(btw, it's a bit annoying that there is no way to rollback the version without restoring an old backup Would be nice if it were possible on the interface)

EDIT: btw, I also tried on a clean install of Transmission : same behaviour. Seems to work fine when there are no torrents, then crashes as soon as I add any torrent.

@girish OK, after a bit more investigation, it appears that the app stops crashing when I remove the transmission-config dir and restart it, then starts crashing again as soon as I add any torrent to download. There appears to be something in the new base image that transmission does not like at all...

@girish Thanks

After a quick investigation, there appears to be a SegFault in the logs:

 Healtheck error: Error: connect ETIMEDOUT 172.18.18.169:90912023-01-10T18:39:17.000Z /app/code/start.sh: line 21: 17 Segmentation fault (core dumped) /usr/local/bin/gosu cloudron:cloudron /usr/local/bin/transmission-daemon --config-dir /app/data/transmission-config/ --foreground
Healtheck error: Error: connect EHOSTUNREACH 172.18.18.169:9091=> Healtheck error: Error: connect EHOSTUNREACH 172.18.18.169:9091=> Healtheck error: Error: connect EHOSTUNREACH 172.18.18.169:9091=> Healtheck error: Error: connect EHOSTUNREACH 172.18.18.169:9091=> Healtheck error: Error: connect EHOSTUNREACH 172.18.18.169:9091=> Healtheck error: Error: connect EHOSTUNREACH 172.18.18.169:90912023-01-10T18:40:18.000Z Starting Transmission...
Jan 10 19:40:19 [2023-01-10 18:40:19.591] Transmission 3.00 (bb6b5a062e) started (session.c:769)
Jan 10 19:40:19 [2023-01-10 18:40:19.591] RPC Server Adding address to whitelist: transmission.zde.land (rpc-server.c:956)
Jan 10 19:40:19 [2023-01-10 18:40:19.591] RPC Server Adding address to whitelist: 127.0.0.1 (rpc-server.c:956)
Jan 10 19:40:19 [2023-01-10 18:40:19.591] RPC Server Adding address to whitelist: ::1 (rpc-server.c:956)
Jan 10 19:40:19 [2023-01-10 18:40:19.591] RPC Server Serving RPC and Web requests on 0.0.0.0:9091/transmission/ (rpc-server.c:1243)
Jan 10 19:40:19 [2023-01-10 18:40:19.591] UDP Failed to set receive buffer: requested 4194304, got 425984 (tr-udp.c:97)
Jan 10 19:40:19 [2023-01-10 18:40:19.591] UDP Please add the line "net.core.rmem_max = 4194304" to /etc/sysctl.conf (tr-udp.c:99)
Jan 10 19:40:19 [2023-01-10 18:40:19.591] UDP Failed to set send buffer: requested 1048576, got 425984 (tr-udp.c:105)
Jan 10 19:40:19 [2023-01-10 18:40:19.591] UDP Please add the line "net.core.wmem_max = 1048576" to /etc/sysctl.conf (tr-udp.c:107)
Jan 10 19:40:19 [2023-01-10 18:40:19.591] DHT Generating new id (tr-dht.c:389)
Jan 10 19:40:19 [2023-01-10 18:40:19.591] Using settings from "/app/data/transmission-config/" (daemon.c:646)
Jan 10 19:40:19 [2023-01-10 18:40:19.591] Saved "/app/data/transmission-config/settings.json" (variant.c:1221)
Jan 10 19:40:19 [2023-01-10 18:40:19.591] Loaded 16 torrents (session.c:2170)
Jan 10 19:40:19 [2023-01-10 18:40:19.591] Changed open file limit from 1048576 to 1024 (fdlimit.c:408)
Jan 10 19:40:19 [2023-01-10 18:40:19.591] Port Forwarding (NAT-PMP) initnatpmp succeeded (0) (natpmp.c:73)
Jan 10 19:40:19 [2023-01-10 18:40:19.591] Port Forwarding (NAT-PMP) sendpublicaddressrequest succeeded (2) (natpmp.c:73)
Jan 10 19:40:27 /app/code/start.sh: line 21: 16 Segmentation fault (core dumped) /usr/local/bin/gosu cloudron:cloudron /usr/local/bin/transmission-daemon --config-dir /app/data/transmission-config/ --foreground
Healtheck error: Error: connect EHOSTUNREACH 172.18.18.169:9091=> Healtheck error: Error: connect EHOSTUNREACH 172.18.18.169:9091=> Healtheck error: Error: connect EHOSTUNREACH 172.18.18.169:9091=> Healtheck error: Error: connect EHOSTUNREACH 172.18.18.169:9091=> Healtheck error: Error: connect EHOSTUNREACH 172.18.18.169:9091=> Healtheck error: Error: connect EHOSTUNREACH 172.18.18.169:90912023-01-10T18:41:28.000Z Starting Transmission...

Hello !
Long time no see
I just noticed that since the newest update of Transmission, 5 days ago, I get a lot of 502s on the web interface, and it is generally extremely slow. No idea why this is happening. I tried restarting the app, it does not help. Anybody else seeing this ?

Which browser / OS are you using ? Did you try different ones ? I seem to remember a similar issue maybe a year ago, but IIRC it only affected firefox or something. Not sure what the root cause ended up being

@girish said in out of space error leading to missing certs:

@roofboard yes, agreed. I don't like it the way it currently right now that filling up disk space brings everything down. Currently, we have a simple cron checker which will give alerts if it's nearing some amount of disk space but this fails in many cases because it runs only every 6 hours or so (it's not run too often to prevent disk churn).

I think a good long term solution is to figure out how to limit disk usage of apps. I think another thread there is a idea that maybe all appdata can be stored in a XFS partition. We can then enforce quotas on apps.

A good shorter term solution would be to allow to configure the level below which the alert is sent. Depending on if you use your server for storing text files, or if you download video, your "low disk" tolerance will be wildly different.

Hardened node developer here : long story short, nothing to worry about.

NPM security warnings are completely broken, they have a near 100% false positive rate (technically, the "vulnerable" dependency is here, but the flaw is, in literally all instances I have seen, not exploitable). An interesting read about this if you want : https://overreacted.io/npm-audit-broken-by-design/

BTW the cloudrons docs page seems to be wrong:

Ackee is a Self-hosted, Node.js based analytics tool for those who care about privacy

I think there was a copy/paste that got out of hand ^^

@wisameldin Temporary failure resolving 'archive.ubuntu.com' => looks like your server has connectivity issues. Or maybe DNS issues. Which provider are you using?

@girish Yes there is. .ipfs is not a "normal" TLD. It's for websites which are on IPFS, which is an alternate decentralized protocol. Kinda like .onion domains for serving websites on tor.

However, i don't really know how cloudron could support it, as I believe it does not use standard http/s at all, so regular apps would not work.

@LoudLemur Basically what @robi said : this driver (or any driver for that matter) will only contain information on how to communicate with the hardware, not how the hardware is made, and especially not why it's made that way.

As an alternative, I know that https://www.seafile.com/ is a file storage solution which offers end2end encryption, but when I last tried it (admittedly a few years ago) the client software was

Basically, what you want for this is end-to-end encryption (and I know a bit about this, it's literally my job to implement E2EE ^^).

The problem is that the nextcloud app that provides E2EE is bad, like really bad, like "my files just disappeared, i have no idea why" bad.

So, long story short, there is no simple way for you to provide this service to your friend with nextcloud with you not being able to look at their files.

@MichaelF Take a look at https://docs.cloudron.io/troubleshooting/#recovery-after-disk-full , if you haven't already

(BTW, hiding your IPv6 address when you show the domain in your curl example is not very useful ^^ dig AAAA hemmer.land gives 2a03:b0c0:3:d0::13ec:f001)

@stormgrass said in IPv6 for Mastodon - how?:

Seeing how both produce different results in my DNS records: is adding the DO-issued address into Cloudron as a static IP the correct course of action, or should I be using the Network Interface instead?

Not necessarily : it is very common that servers get assigned a /64 IPv6 address : that means a bloc of IP addresses where only the first half is common, and the second half can be anything.

If the 2 addresses have the same first half, there's nothing weird about the results being different.

If not, there's something afoot.

Also, about your curl test failing, dumb question but are you sure that your local machine has IPv6 connectivity ? To test, you can try something like ping6 google.com

@binary1zero From the constraints you mentioned, I do not understand why you don't simply use the home server as a main email server, but with an external relay for outgoing email (assuming your ISP does not block inbound 25).

From what I know, PTR and stuff is only necessary for outbound relay, as it mostly affects server reputation when other server decide incoming email is spam.

I believe cloudron is not compatible with OpenVZ. Source: https://docs.cloudron.io/installation/#install_1