Cloudron Forum

@nebulon I will build up real experience and report here

@girish When we initially changed the default data directory and restarted the entire Cloudron server, something went wrong. As a hotfix, we applied some basic permissions, which probably broke PostgreSQL. However, we don’t know which permissions were wrong, as I didn’t log them at the time. This morning, we tried changing the default data directory again, but instead of restarting the whole Cloudron, we restarted all services individually, and this time we didn’t get any errors.

Thanks @girish for the changes in the docs and letting me know. I will take a look as soon as the time allows and may get back to this topic at a later date.

@humptydumpty said in At home self-hosted Cloudron - migrate to larger main disk. Advice and sanity check my thoughts.: Having a GUI is preferable. I would also have recommended dd Something I havent used in ages, but i think would satisfy the gui criteria is https://clonezilla.org/

fyi: As soon as I have moved platformdata back to the “original” storage, everything works as expected the error disappeared. I also had to move the appsdata & boxdata back to get a fully functional Cloudron instance again.

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: 1715934680451-d1ca53cb-6e7f-468e-9abc-e05540baea9f-image-resized.png] Step4: Copy the JSdelivr link to your Typebot. [image: 1715934804835-5677227c-ec50-4db0-95f9-38de57586ecb-image-resized.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