Upgrade to Electric Eel - Minio Apps Problem - Please ensure MinIO binary has write permissions for the backend

Good morning,

we have upgraded to the lastest version Electric Eel - now every minio instance keeps crashing with the following error:

Please ensure MinIO binary has write permissions for the backend
Unable to initialize backend: Unable to write to the backend Run the following command to add write permissions: \sudo chown -R . && sudo chmod u+rxw

Someone has the same problem after the upgrade?

Thank you

My MinIO App seems to be running fine. (I know it’s not the response you’re hoping for, but the app itself seems to run OK. I’m sorry you’re having issues! :crying_cat_face:)

1 Like

When I was digging around I found that there is script that runs for setting permission. I don’t know why anyone complicated everything but for some reason Minio looks for 473 uid/guid. I just ran chown -R 473:473 on the dataset and everything started to work. We need a configuration option in the app to set the user minio runs as so that we can set dataset permission accordingly

Unless I’m missing something, docs still say user apps (uid/gid 568) for, well, apps. Not sure where minio and 473 came from, but setting env PUID/PGID 568 should work, but it’s not for me.

I’m just encountering the same error on a clean install of 24.04 yesterday

My understanding is that while minio runs as uid 473 it has membership in 568 as a secondary group, so granting permissions to any hostpaths to have this access should function.

@HoneyBadger
In my case, upgrading from 24.04 to 24.10, no user minio or 473 exists.

Have you deployed the enterprise or stable train app version?

Sounds like you have ACL permissions issues. You can resolve these by editing the app settings, selecting Enable ACL, navigate to the host path for your datasets, and add an ACE Entry, select user, then add the 473 UID with full permissions, you can add another ACE Entry for the 568 UID.

You can also edit the ACL from the Datasets screen, select the dataset row, scroll down to the Permissions widget, click Edit to open the Edit ACL screen.
Add ACE entries for netdata user (473) and give it full control permissions.

The tutorials for MinIO are updated with instructions for 24.10

Stable.

Per my comment here, no user w/uid 473 exists.

Was something missed when migrating from a k3s-based environment?

In a fresh install, what should the users look like?

I’d prefer no (what I’d consider) hackey ACLs when this should work out-of-the-box.

the run-as users should show on the MinIO apps details screen, but 473 is the default user for MinIO. If this is not showing or you get an error when you try to set the ACE Entry for this, download a debug and open a bug report ticket.

It is possible something when wrong with the upgrade but we’d need the system debug to see what happened.

Try the above, please. We’ll help figure out what went wrong.

I’m sorry if I wasn’t clear, but yes, I see the run-as uid 473, however, 473 doesn’t exist on the system.

I did manually create a MinIO User w/uid 473, ensured it had full access c/o ACE+ACL.

root@xxxx[/mnt/pool1/minio]# ls -al
total 48
d--------- 3 apps apps 3 Nov  8 13:59 .
drwxr-xr-x 5 root root 5 Nov  7 09:20 ..
drwxrwx--- 8 apps apps 9 Nov  8 14:05 .minio.sys
FATAL Unable to initialize backend: Unable to write to the backend
      > Please ensure MinIO binary has write permissions for the backend
      HINT:
        Run the following command to add write permissions: `sudo chown -R <your-username>. <path> && sudo chmod u+rxw <path>`

Please open a ticket on this and upload the system debug when prompted to the private attachment area.

1 Like

Has anyone solved this issue? I have the same problem in ElectricEel-24.10.2 using MinIO stable RELEASE.2025-02-07T23-21-09Z. The problem is the same even when using a host path or ixVolume. I am doing a fresh installation of a MinIO instance.

I was able to solve this. The TrueNAS system in question is a virtual machine used for testing. Due to some virtual CPU settings, MinIO crashed with a glibc error. The main issue was that this error wasn’t logged anywhere. The crash was too immediate to capture container logs from the WebUI. I found the error by attaching to the container using raw Docker commands in the shell.