Cloudron Forum

@thebighead please update to 7.4.1 and try . Settings -> Check For Updates and update.

@nebulon
How can I change it, I tried it and restart the server but it didn’t work. Can I install a older cloudron version ? 7.3.9?

@girish Your question got me wondering what was going on.

Turns out, two apps on the volume both had caches that were insane (one due to an old uninstalled WP cache plugin that was removed, but maintained its 12 MILLION cached files, and the other was Mastodon, which needed some manual cleaning for the 800k files it had cached).

Turns out there were just SO MANY folders/files that any attempt to backup or read the size would just time out.

D'oh! 😖

@privsec you can play with rclone mounts for this, however you want to minimize the network distance to avoid hiccups.

Ah, I guess the error message could be more descriptive. Currently there is a hard-coded allowlist of paths on the filessystem to be used as volumes, to avoid accidents where someone might add system folders. The list is at https://git.cloudron.io/cloudron/box/-/blob/master/src/volumes.js#L57

@zion I am not sure I fully understand your process there, but generally a disk partition is just a section of a hard drive. That section then has to be formatted with a filesystem, in this case ext4. This can be done via mkfs.ext4 /dev/<you partition identifier>. Once that is done, you should be able to just use the Cloudron dashboard UI to add it then. This makes Cloudron create the mountpoint for you.

@nebulon Thank you. After checking, it turned out that the issue is about efs not mounted.

It seems to be messed up with security groups and/or network interfaces (eni). Hence closing this threat for now. Need to dig deeper and probably understand the concepts of security groups and eni better in AWS.

Thanks for your help!

Edit: Just realizing that can't set it to 'solved'

@girish Thanks for taking the time to ponder on this !

Yes you got me right and I understand why it's not possible in the case of nocodb.

just FYI, the path nocodb use in the cloudron context to store uploaded files is
/app/data/nc/uploads/noco/{NameOfTheDatabase}

f9e7d383-3c20-4693-9060-caf2008b655f-image.png

Your suggestion to link directly to the LAMP or to a static "mirror" of this is the path I finally went with, it's was the logical step since provided I can link to it, where the media is does not matter much.

i'm not yet releasing this publicly but it's coming !

Thanks for the help!

Maybe there was some bug in our migration path. Will keep an eye out for related bug reports.

@msbt We won't break it intentionally atleast.

@SamGreenwood please give us more context via screenshots of what you're looking at.

In general cloudron won't allow you to map volumes if they're not there, or move storage to the wrong mount points.

@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.

In 7.1 atleast, this seems fine:

1c2d66a7-2e5f-4590-b935-685d949310b8-image.png

@nebulon Had to wait a few days to execute on moved cloudron server.
all resolved now.
Thank you for this.

@fbartels The thing is I can't check since the volume now works for me. But what I'm saying is that the issue was wider than just not being to write with the NC app, since data in the volume was not read / written into correctly anywhere (in NC app, in NC terminal and in Cloudron file browser) and that has nothing to do with the www-data user as far as I can tell.

And by the way you are right that the user in the terminal is root so it's true that being able to write with the terminal could still mean there is a restriction on the folder which would prevent the NC app to write. But as explained above, I don't believe this was the problem in my case.

Ah, thanks for reporting. I have opened https://git.cloudron.io/cloudron/box/-/issues/808 internally .

@girish since it worked with my other NAS, I am pretty confident now that it is rather a Permission-Issue on the TrueNAS-Side which I dont understand well enough as of yet.

Thanks for the link!

@3246 @girish , I am not sure (didn't try myself) but things suggested in this post may help ..

@mehdi thanks for reporting, this is fixed now. Next time a separate thread might be better to track those things if possible.

Amazing, and makes all the difference!