Cloudron Forum

I think we have to go back to the original question. What's the original issue? Using tools like df in /var/lib/docker/overlay2 won't work.

@murgero Thanks, yeah, definitely not doing that now 😓 Just looking for the simplest solutions with what we already have.

Since the functionality is already there, this is more of an workflow interface feature to just make it available at an earlier stage in the process, and to avoid the additional step and decisions later to do the exact same.

What @Dont-Worry said. As long as it' mountable on the server as Cloudron Volume, it should work without a problem. With NAS and network storage, one thing to keep to mind is the flakiness/stability of the network. Apps can behave erratically if the attached storage is not stable.

@d19dotca it seems the yarn cache was note cleared. Clearing it brought down the size . It's in the new package.

@Dont-Worry the apps run as containers and each container has it's own file system (completely different from the host filesysted). It is a sort of sandboxing for security.

What this setup means is that, even if your disc is attached to the machine, the app containers won't see it! It will be available on the host ubuntu itself but not to the apps. Cloudron Volumes is a mechanism to expose these discs on host to the apps. Hope that clarifies!

But if I could use it as a classic disc, I should mount it as a Cloudron volume If I understood correctly.

Right, and there is no way around not creating a volume.

It seems the options --storage-driver=overlay2 makes docker unable to start when the data-root is on a mounted through sftp : adding it through the following error at startup

failed to mount overlay: invalid argument storage-driver=overlay2

if I use it with a regular data-root, no errors show up. I guess we should conclude that this makes cloudron not compatible with sftp drive for storing docker images.

Not tried it myself but https://docs.castopod.org/getting-started/install.html#install-instructions

One article was saying that Hetzner is a South African company, that they existed in a previous incarnation there and are now Xneelo...

https://xneelo.co.za/dedicated-servers/

@bmann Yeah, in that case, I'd say just use a provider that allows you to buy extra storage inexpensively and mount it as a volume. BuyVM is the one that comes to mind honestly.

You can also use CIFS or NFS, but I don't know how well I'd trust them as primary storage for an app.

Also, as said, some apps support external S3 (although that limits your capability to fully encapsulate your backups).

To answer the original question: I think root user is the first/admin user that you signed up with Wasabi. If you create users after that, they are called sub-users. Depending on your setup, you have to create a key for the root user or sub user. I guess you can just create the key for root user if you are not using sub-users. See https://docs.wasabi.com/docs/creating-a-user-account-and-access-key

Tyvm, saved my day!

This is very easy to solve! You don't need any S3 storage just to serve images. That's like using nuke to bomb an ant. Here is the solution:

Step1: Create a repository on your github account.
Step2: Upload an image (e.g. bot avatar) to your repository.
Step3: Copy the link of your image, then paste to jsdelivr (select "convert from Github").
image.png
Step4: Copy the JSdelivr link to your Typebot.
image.png

Now, you have a world-class CDN provider serving your image FOR FREE!!!
This link is permanent unless you purge it!

@jdaviescoates said in Cheap Good and Fast Block Storage Options:

What do you actually want to do?

Thanks for asking! For Cloudron backups, that is no problem. What I want is storage for app data, for example, the images in a gallery application, or the videos in a video application. From what I understand, these have to go to a block/object storage with the same VPS, as Girish explained here:
https://forum.cloudron.io/post/71151

Basically, if I understand correctly, with Cloudron, your VPS provider has to also offer block/object storage too, if you want to backup your application data on a different server. For example, Hetzner storage boxes would only be useful for app data storage if you are running your Cloudron on Hetner, too.

You could also use rclone together with mergerfs to create some kind of layer.
like
/mnt/remote
/mnt/local
/mnt/mergerfs

You then write stuff locally, and it'll upload stuff in the background to your remote storage.

You can look for inspiration @ https://github.com/l3uddz/cloudplow

@nebulon the doc might need to be updated

systemctl stop|start docker docker.socket postgresql mysql nginx for the services.

rsync --archive /mnt/old_root/home/yellowtent/boxdata /mnt/data/cloudron-mail/ for copying the data (mv when fails produce a whole set of problems to be resolved and can't be resumed).

and the following commands to verify:

find /home/yellowtent/boxdata/ -type f -printf "." | wc -c find /mnt/data/cloudron-mail/boxdata/ -type f -printf "." | wc -c diff -r -q /home/yellowtent/boxdata /mnt/data/cloudron-mail/boxdata

@Stardenver Depends on how you use the volume.

If you use the volume to store the app's data using data directory , then it's part of backup If you set it up as a mount of the app, then it's not.

@girish I recall you making that run automatically..

Should it run more frequently?

@Neluser Good idea. But it's quite complicated to automate things like this, that's what it's not done. But something to keep in mind. In the meantime, following https://docs.cloudron.io/storage/#docker-images is the way to go.