Electric Eel app migration issues related to ACL

Apps and Virtualization
1

Hey there team,

Recently swapped over to Electric Eel and have had a nightmare of a time trying to migrate my apps.

Have been trying to run the command midclt call -job k8s_to_docker.migrate tank and have had success with some apps but with the vast majority I get the error
[{"name": "App", "error": "Failed to create app: [EINVAL] app_create.storage.additional_storage.0.host_path_config.acl: "path to config": path contains existing data andforce was not specified\n

I have flick back to the previous update and change some of the original configurations of the app. ensuring some have “force” flag enabled and that other have ACL disabled completely. No effect for either. The ACL permissions on the affected dataset are setup in the way I would assume is appropriate with "apps’ being owner and user and having all permissions for that dataset. All of the apps I was running are setup as a single user.

All my apps where working flawlessly at time of upgrade.

My intent is to A) work out if there is something silly I am doing or if this is an wider/known issue which may effect others and B) work out if there is an easy fix - IE change force flag in shell or adding specific ACL entry to bypass.

I am running the latest update on the TrueNAS-SCALE-ElectricEel-BETA train on a dual e5 64gb ram server.

Thanks in advance!

2

Have you confirmed that the apps you’re trying to migrate are listed as ready for migration on the repository?

1 Like
3

yes I have - that was my first check before upgrading.

Even if they weren’t I doubt this would be the error thrown

4

To answer in the general sense, apps may specify a particular ACL for the host-path data to grant permissions that are determined to be required for the app in question.

The reason why we use ACLs for this is that if a host path is being accessed by more than one app then there may be multiple uids / gids that need differing levels of access to it. This is to simplify matters for users when initially deploying apps. IF the specified host path already has files written to it, we will not automatically change the ACL since in $place-of-work this could create a double-unfun security incident.

Although you could technically chown all the data to the uid a particular app is running as, this is generally a bad idea as (1) you lose useful history about who created the file and (2) the app gains elevated permissions as to all files in that particular tree.

IIRC there is some work for RC1 to make this more advisory and leaving it up to user to fix.

2 Likes
5

Thanks so much for this, that’s a helpful answer.

can I confirm, if I’ve understood this correctly, that because of this approach to ACL, and because we have no fined grained control over “k8s_to_docker.migrate”, that if we are running into this issue we will need to re-create all affected apps in electric eel and will not be able to migrate?

I don’t think there is anyway, other then maybe removing all specific acl and then upgrading, to avoid this.

6

Electric Eel is in BETA. We’re working off the rough edges. As I mentioned this will be something more advisory in the actual release.

1 Like