Cloudron Forum

As far as I understand those CVEs they are not relevant in that context. For the first, we don't use those affected configs and the second is for the ssh-agent.

Given that the Ubuntu team usually knows what they do and are working closely together with upstream projects, there seems no need here to go beyond their recommendations of versions they push out via security updates.

@michaelpope yes, I've seen some people being concerned about it. But it's either you are a very large deployment, or people with small but very special deployments.

For the typical cloudron use case this should not matter.

Ps: i have not watched the video

Okay, I figured out what my problem was.

I had some failed backups from yesterday, when I tried to get hardlinking working (and I also had a permission issue with the MySQL dump). As of such, I cleared the backup disk manually, and then triggered a backup cleanup in the Cloudron UI. Then I tried to back up again, however, I believe that Cloudron keeps an index of files it has already backed up to keep things speedy (which is nice). As of such, even though the other files no longer existed, it was only backing up the changes.

To solve it, I just changed the backup method to a different method, and then changed it back again, which cleared the index.

Thanks for all your help on this :).

Hey all, reinstalled and then did a restore to fix things. Had a few trouble with restore, but was able to work them out. Also wrote a quick rsync command to take the emails from lost+found and restore them to their proper directories, so no emails lost :).

Sweet and thanks, I figured as much :). I'll have to check out the partition table change.

Thanks so much for your help on this.

@jdaviescoates Woops! Fixed 🙂

I am no WOPI expert and also cannot reproduce this still. A 403 status code would to me more look like the accesstoken (which is different in both requests you pasted) is invalid. But could be that Nextcloud does return a 403 also for blocked IPs. You have to ask the upstream developers for such details.

One idea, can you double check which IP range your local cloudron docker network uses? You can do this via SSH docker network inspect cloudron

@jdaviescoates 🤭

@girish Sure thing!

@girish Did some testing. I think you are right. The distance is reducing the bandwidth I guess.

@LoudLemur I use the smallest VPS with SSD (Cloud VPS S). For my small family (e.g. for using Nextcloud and Vaultwarden) this is more than sufficient, at least for my needs.

@BrutalBirdie So I figured this out, and it's definitely NOT a Cloudron issue. Actually, it's a Thunderbird issue... so I'll probably go write a quick report on Bugzilla at some point.

It turns out that when you hook up two emails for Thunderbird that (1) go the same mail server and (2) share the same password, that causes Thunderbird to ignore the username.

What this means:

Let's say you set up two mailboxes in Cloudron, your.name@company.com and service@company.com. While your.name@company.com is accessible to you, service@company.com is instead accessible to a group you are a part of. You can use user account password to log into both.

Let's say you first add your.name@compay.com to Thunderbird. It will work fine. However when you add service@company.com, outgoing will be messed up (though incoming will work). Rather than outgoing being registered for service@company.com, it'll go out through your.name@company.com, which is not the correct behavior.

You can fix this by going into Outgoing Servers in Thunderbird, but it's a big pain it doesn't need to be, and I'm sure it's something that can be fixed on the Thunderbird end.

Anyways, that was a fun dive into some email issues... hopefully I can get this fixed and jump back into using groups, as that helps make security issues with emails a little easier to deal with (no having to reset everybody's shared password).

Hope you all have an awesome day!

@d19dotca I can't believe I missed that. Literally read right past it. Thank you!

@michaelpope Fully agree with improvements to the retentions feature. I've never really understood why the retention policy isn't customizable - I'd love to see it be improved not so much with static additions but to a point where it can be customizable so I can pick how many I want to keep for each time period (daily, weekly and monthly). So I could for example pick to keep the last 4 days of backups while also choosing to keep a weekly backup for the last 6 weeks for example, or maybe I only want the last 5 days of backups and nothing more, etc. Hopefully that can be improved down the road.

@girish This makes a ton of sense, although I'm not quite sure if I'm doing it right. Under what you linked to, the section should be under the Resources tab, although I think it's moved to the Storage tab (no problems with that, I just wanted to make sure I'm handling it correctly).

2dfb1d41-c351-4f45-8352-99a9505b43d2-image.png

99f01fc2-bf27-42bb-8de1-dc11eaff4e2b-image.png

The part that's a little confusing is how 'App Data' and Volumes tie together in storage (now it seems this may be resolved as you said, since your working on Volume updating at some point in the future).

Anyways, App Data says to mount an external EXT4 disk, which I assume is done with the 'Mounts' interface right below it. However, the mount says that you are mounting 'Volumes'.

The documentation says 'App Data' is backed up. However, the documentation also says that 'Volumes' are not backed up. So that does leave me a little perplexed as to whether the data will be backed up or not. I think according to your comment, that it will be backed up (because you did say it would no matter where it is on the server). But I just thought I'd check 🙂

In any case, thanks for your help, and hope you have an awesome rest of your week.

Sorry, this was a duplicate post, because the first didn't go through for a while. Please ignore, and answer the question in the other forum.

@nebulon That's awesome! Thanks so much! It's gonna make running the server a lot more affordable :D.