Please move this issue to:-
https://forum.cloudron.io/category/91/peertube

@girish Looks like its not old images.
2.png

Here is the output of du -hcs /*. I also have raid on /mnt/md0 so you can ignore that.

@girish If I try to uninstall it again, the same error just pops up...

logs

Jan 16 19:08:23 box:apptask accounting.xevotech.com deleting app containers (app, scheduler) Jan 16 19:08:23 box:shell removeCollectdProfile spawn: /usr/bin/sudo -S /home/yellowtent/box/src/scripts/configurecollectd.sh remove 700a273d-3bb1-4957-8d6d-239d5ee27385 Jan 16 19:08:23 box:shell removeCollectdProfile (stdout): Restarting collectd Jan 16 19:08:23 box:shell removeCollectdProfile (stdout): Removing collectd stats of 700a273d-3bb1-4957-8d6d-239d5ee27385 Jan 16 19:08:23 box:shell removeLogrotateConfig spawn: /usr/bin/sudo -S /home/yellowtent/box/src/scripts/configurelogrotate.sh remove 700a273d-3bb1-4957-8d6d-239d5ee27385 Jan 16 19:08:23 box:apptask accounting.xevotech.com updating app with values: {"containerId":null} Jan 16 19:08:23 box:tasks 5786: {"percent":30,"message":"Teardown addons"} Jan 16 19:08:25 box:addons accounting.xevotech.com teardownAddons: Tearing down ["mysql","localstorage","sendmail","ldap","scheduler"] Jan 16 19:08:25 box:addons accounting.xevotech.com Tearing down addon mysql with options {} Jan 16 19:08:26 box:addons accounting.xevotech.com Tearing down addon localstorage with options {} Jan 16 19:08:26 box:addons accounting.xevotech.com teardownLocalStorage Jan 16 19:08:26 box:taskworker TypeError: Cannot read property 'device' of null at /home/yellowtent/box/src/docker.js:670:41 at /home/yellowtent/box/node_modules/dockerode/lib/volume.js:44:7 at Modem.buildPayload (/home/yellowtent/box/node_modules/docker-modem/lib/modem.js:273:7) at IncomingMessage.<anonymous> (/home/yellowtent/box/node_modules/docker-modem/lib/modem.js:232:14) at IncomingMessage.emit (events.js:203:15) at endReadableNT (_stream_readable.js:1145:12) at process._tickCallback (internal/process/next_tick.js:63:19)

Right you can also check with curl if it's a browser issue or not? curl https://slappersonly.co. curl will get self-signed cert error if there is some cert issue. You can also do host slappersonly.co to see the IP it is resolving to.

Using remote mounts also with volumes does add some possible race and inconsistency it looks like. So on Cloudron docker has to be started before unbound, now the remote mounting requires unbound for DNS resolving, however depending on how fast docker containers come up, they require volume mounts, which in turn, if depending on the remote mount points, we end up with some circular dependency.

The systemd automount would attempt to mount a remote once anything accesses the mountpoint. So if docker is quick enough and you have assigned some volumes from a mountpoint for a container, then again it would attempt to mount this before unbound is working.

For a start the automount will solve the issue of using a remote storage as a backup storage. When used with volumes, I think only using IPs will work for now.

@cbeams Whoops, you are right. It's indeed bookstack and not wikijs!

Also, I think using cloudflare as a front to wikijs should work. Let us know if it doesn't.

Got it, thanks @p44 and @jdaviescoates.

@savity said in Backup Fails NEXTCLOUD:

But i don't see any errors in the Backup Logs?

So what is in the logs? Can you paste the last 100 lines or so to https://paste.cloudron.io ?

don't forget the network timeouts with optimized TCP settings, which can disconnect too early.

@atrilahiji said in Installation gets stuck in "checking DNS" step:

@jakobgreenfeld Oh I missed the bit where theres only a txt record. Add an A record pointing my.domain.com to your IP. I've had nothing but trouble with Namecheap's API for configuring everything so I've started doing this:

A record for *.domain.com
A record for @

That did the trick! It's working now. Thanks!

@nebulon

Anyway i am happy to upgrade tomorrow to a paid package, this is truly great support!

Thanks!

@girish perfect, thanks! I’ll play around in there and see if I can get this sorted.

@girish That fixed it. Thanks!

@robi for the first logviewer mismatch, this is because the first time shown is from the logservice itself and is translated into the local time of your browser, whereas the second comes from the app itself and is just treated as a plain string. Apps normally run in UTC.

For the winscp part, I am not sure how winSCP translates timestamps. The folder names are set from server time.

I don't think any of this will have anything to do with DB reconnection, if you have any issue there, please make a new entry in the TS forum section with some more info.

@girish Ok I'm dumb... I had quotation marks around the LD_PRELOAD variable I added in this file: /etc/default/collectd

Seems to work now. This can be closed, sorry!

@dkdkdkk what I do in similar cases is quite simple : allow routing between the 2 VLANs on the router.

So, your Cloudron and the camera would be able to talk to each other directly. And you can still only allow the first VLAN to route to the internet. That's what I'm doing for my "smart home" stuff. This should check all your boxes 🙂

@nebulon Maybe https://askubuntu.com/questions/1210867/remount-cifs-on-network-reconnect ? (just expands on your link)

@cdolson How are the speeds?

@girish
I'm having I think the same issue. I have server logs on the recieving side I can share as well. here are the details

Here is my setup:

me@SenderServer.com to send the test mail me@DestinationServer.com is the final destination address we are forwarding to and where server logs are recovered from me@MyCloudron.io is set to forward to me@DestinationServer.com MyCloudron.io which has ip 1.1.1.1 is the cloudron install
NOTE: 1.1.1.1 is fake. The real IP is a dynamically changing IP address from the ISP which is likely spam blocked. Prior to setting up the STMP relay server no outgoing emails would work as they would be blocked on the destination server due to ISP's all adding dynamic ip blocks to spam lists by default. After setting up the relay I was able to send as me@MyCloudron.io, and that still works, just forwarding does not work. I suspect, or wonder, if sogo and rainloop are properly using the cloudron configured smtp relay? MyCloudron.io is setup to forward mail through a posteo.de server using a paid account. This works fine for sending and recieving using me@MyCloudron.io directly but me@MyCloudron.io forward to me@DestinationServer.com fails.

The forwarding was setup using sogo.

Error on MyCloudron.io

{ "ts": 1609960307783, "type": "bounce", "direction": "outbound", "uuid": "860650A1-438F-48AB-9CFE-79A20126D25A.1", "mailFrom": "<>", "rcptTo": [ "<me@SenderServer.com>" ], "details": { "message": "554 kundenserver.de (mxeue112) Nemesis ESMTP Service not available No SMTP service IP address is black listed. For explanation visit https://www.ionos.com/help/index.php?id=2425&ip=1.1.1.1&c=bl" } }

logs from DestinationServer.com that appear when the cloudron server attempts to forward to me@DestinationServer.com:

2021-01-06 19:11:47 no host name found for IP address 1.1.1.1 2021-01-06 19:11:47 H=(MyCloudron.io) [1.1.1.1] sender verify fail for <SRS0=0ad3=GK=SenderServer.com=me@DestinationServer.com>: Unrouteable address ==> /var/log/exim4/rejectlog <== 2021-01-06 19:11:47 H=(MyCloudron.io) [1.1.1.1] sender verify fail for <SRS0=0ad3=GK=SenderServer.com=me@DestinationServer.com>: Unrouteable address ==> /var/log/exim4/mainlog <== 2021-01-06 19:11:47 H=(MyCloudron.io) [1.1.1.1] X=TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256 CV=no F=<SRS0=0ad3=GK=SenderServer.com=me@DestinationServer.com> rejected RCPT <me@DestinationServer.com>: Sender verify failed ==> /var/log/exim4/rejectlog <== 2021-01-06 19:11:47 H=(MyCloudron.io) [1.1.1.1] X=TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256 CV=no F=<SRS0=0ad3=GK=SenderServer.com=me@DestinationServer.com> rejected RCPT <me@DestinationServer.com>: Sender verify failed ==> /var/log/exim4/mainlog <== 2021-01-06 19:12:22 TLS error on connection from (MyCloudron.io) [1.1.1.1] (recv): The TLSconnection was non-properly terminated.