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

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