Agreed, I think we should open up a separate app request for this minio console.

@fbartels ok that makes total sense, thanks!

@girish wow, thank you for figuring that out.

Strangeness of the most High.

@timconsidine intuition FTW 😉

@fbartels thanks, I think you're right

@girish
Thanks for clarifying. I think I was just looking in the wrong place / expecting this to workm differently. No, I am not aware of a UI for this in non-Cloudron instances, though this would be nice to have of course.

Thanks for the heads up. The new package is out now.

@girish ooooo - so each backup stands on its own. That makes sense from a recovery perspective. I suspect it'd be a groovie feature to add though for Nextclouders and Jellyfin types so they know they have one good backup. In my case, disable backups of Jellyfin and back up and goin.

@robi will inquire!

@girish It's no problem - just a tad bit of overhead and I use the S3 for other backups anyways.

Yeah, the volumes work great - in my instance it looks like this:

-External hard drive via USB3 hooked to physical box
-Hard drive volume created on physical box with an 8 TB VHDX on there.
-8TB VHDX passed through to Cloudron VM
-Cloudron VM mounts it as an xfs target
-Pass mount (the /mnt requirement tripped me up but is smart to require it) to Cloudron
-Mount volume into Minio container (/media/backuptarget)
-Reconfigure minio to default to /media/backuptarget instead of /app/data/data
BOOM

(The last bit is why minio CLI's fuss cause /app/data/data is hardcoded in a few places).

@nebulon for me it is no issue anymore because of the Volumes. In this Minio app I don't share the Volume with other apps and it's not backed up just like I want.

Hopefully in future releases, like @girish wrote, when they will be backed up there will also be an option to never backup specific Volumes?

@girish weird, "./" was the first thing I tried when it didn't on its own but there again it threw me an error about command not found and minio-credentials not being a folder. I resorted to trying bash in case I got it wrong and that's the only time it at least tried to run something (but ran into those errors).
But have just done it again and it worked fine, I must have done something wrong the first time.
Sorry for reporting a non issue and thanks for getting back

taken from https://my.example.org/#/system

/dev/sda4 mounted at /home
This ext4 disk contains: ...

@girish Thank you, awesome replies!

Fixed in https://git.cloudron.io/cloudron/minio-app/-/commit/6eb1e7b4b9bbb3f8a2c1e44ac6d78b232ed79162

AFAIK, there is no such limitation. Indeed, I am able to add as many users as I want:

girish@benton:~/tmp$ ./mc admin user add minio newuser newuser123 Added user `newuser` successfully. girish@benton:~/tmp$ ./mc admin user add minio newuser1 newuser123 Added user `newuser1` successfully. girish@benton:~/tmp$ ./mc admin user add minio newuser2 newuser123 Added user `newuser2` successfully. girish@benton:~/tmp$ ./mc admin user add minio newuser3 newuser123 Added user `newuser3` successfully. girish@benton:~/tmp$ ./mc admin user add minio newuser4 newuser123 Added user `newuser4` successfully. girish@benton:~/tmp$ ./mc admin user add minio newuser5 newuser123 Added user `newuser5` successfully. girish@benton:~/tmp$ ./mc admin user add minio newuser6 newuser123 Added user `newuser6` successfully. girish@benton:~/tmp$ ./mc admin user add minio newuser7 newuser123 Added user `newuser7` successfully.

Then:

girish@benton:~/tmp$ ./mc admin user list minio enabled newuser1 enabled newuser2 enabled newuser3 enabled newuser4 enabled newuser5 enabled newuser6 enabled newuser7 enabled newuser

@RoboMod Sure, sorry for the no response. From the logs in the other post, the error is Message: Connection timed out after 300000ms HTTP Code: TimeoutError. Maybe the server becomes unreachable because of some network error? Is that possible in your setup?