@felixbmmm said in MinIO: Infinite loading when previewing or downloading file:

I ran MinIO's docker image then access its browser console

Just to double check, are you even using Cloudron ? This is the forum for the minio package on Cloudron (and not for the upstream docker image). Upstream questions should be posted at https://github.com/minio/minio/discussions

@fbartels said in Amazing app to help with backups and saving space!:

For domain style buckets to work with Cloudron, the Cloudron app would need to support domain aliases.

Sounds like perhaps @staff should add the aliases feature to the Minio app

@girish Thank you

@girish yay ! 🍾
Despite the hour I couldn't resist trying it.
I changed the location of the api from minio-api.domain.tld to minioapi.domain.tld (just removed the hyphen) and saved the change.
Renewed certs and logs now show the api domain in there.
Tested with Minio mc CLI and Forklift : they both list buckets and contents.
Will check MountainDuck and others later.

Thanks for your patience and support.
Marking it solved ! 🍾

I did a full run of update testing now.

After upgrade, I was able to login with my previous root credentials.

After upgrade, indeed, the env variables are not injected. I have put an example in docs now - https://docs.cloudron.io/apps/minio/#admin-credentials . New installs have these variables.

I was able to reproduce the clone issue. Was easy to fix. I guess this will be useful in case one wants to inspect older backups in the future.

The restore is a bit more complex - Made an issue https://git.cloudron.io/cloudron/box/-/issues/814

I put this info in https://docs.cloudron.io/apps/minio/#access-keys

@jdaviescoates Check out my answer to your other question about the Keys! Basically, Minio views Access Key/Secret Key as the same as User/Password, so by clicking to the User section in Minio you can reset the Secret Key.... but it's called "Password" in this Dashboard! Not too intuitive. Then, use your self-hosted VaultWarden or Joplin to save your newly reset Access Key/Password!

@timconsidine said in Changed credentials does not work for login:

But isn't /app/data potentially reachable from internet?

/app/data is just the part of the file system that the app can write to. It is only reachable via the Cloudron dashboard.

@girish Thanks a lot for this. Yes I will ask there then.

The upstream answer is good to know that minio won't work on FUSE.

@girish
Thanks girish

@girish said in Possibly breaking changes in next package:

two endpoints

maybe we can add support for multiple http port in the manifest?
so one subdomain go to a port for S3 and the other for the console.

EDIT:
Just see that you post my same conclusion on the minio git discussion

https://docs.min.io/minio/baremetal/security/ad-ldap-external-identity-management/configure-ad-ldap-external-identity-management.html#minio-authenticate-using-ad-ldap-generic

I am currently checking whats going on with LDAP and the new console.

https://git.cloudron.io/cloudron/minio-app/-/merge_requests/2

@brutalbirdie said in So what am I doing wrong?:

First of all, PLEASE DON'T USE PICTURES / SCREENSHOTS FOR LOGS!
This makes the information inaccessible to some users (for example blind ones) and also it's a pain to read.
Simply copy the output press the Code Button

And put your copy-paste here.

@privsec simply said, you are using the shell incorrectly as pointed out by @fbartels

Also as @robi pointed out just read the docs.

You try to access minio-credentials which does not exist in the context as for example cp | rm | mv.
For example you can check if mv does exist by doing this:

/app/code# which mv /usr/bin/mv

And the shell tells you mv is located in /usr/bin/mv, when you try this with minio-credentials you will get this

/app/code# which minio-credentials /app/code#

aka no result. So minio-credentials does not exist as executable in the system paths context.

minio-credentials is a binary file in /app/code/minio-credentials which IS executable but the relative or full path is needed.

So if you would have followed the doc and copy-pasted

/app/code/minio-credentials set NEWACCESSKEY NEWSECRETKEY

it would have worked.

I never thought of accessibility issues, thanks for pointing that out. Ill adapt.

Ok, I will try that, thanks all.

@fbartels ok that makes total sense, thanks!

@girish wow, thank you for figuring that out.

Strangeness of the most High.

@timconsidine intuition FTW 😉

@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