search

truenas / charts

TrueNAS SCALE Apps Catalogs & Charts
BSD 3-Clause "New" or "Revised" License
296 stars 282 forks source link

gitea app - auto permission change does not work with host path volumes #1992

Closed toscdesign closed 7 months ago

toscdesign commented 8 months ago

my next issue with apps on TrueNAS scale 23.10.1 This time with Gitea from the TrueNAS Catalog, Chart Version 1.1.8

I tried to install the Gitea app with host path volumes.

In the description it says, that the permission get automatically changed on first startup: "When application is installed, a container will be launched with root privileges. This is required in order to apply the correct permissions to the postgres directories. Afterwards postgres will run afterwards as a non-root user (999)......"

But this doesn't work on host path volumes. I had to change all permissions manually on the datasets to get gitea to work.

With out the manual change, it gets stuck at "deploying" and the log of the gitea container states "permission denied"

It is the second issue with apps on TrueNAS Scale since update to 23.10.1. I upgraded from TrueNAS 22.12.4.2

stavros-k commented 8 months ago

I just did a fresh install to check that, and the postgres data directory gets its permission fixed on hostPath. (Backup directory perms will only be fixed during an upgrade). Plan is to also move away from touching user directories on postgres directories too, but needs some more work.

This is because those directories are not managed by the system and you can't know the exact setup user has. Which is why we limiting applying permissions only to ixVolumes.

Note that gitea's directories are not touched when hostPath type is selected. That's up to you to fix (or use the ACLs from the UI).

toscdesign commented 8 months ago

The issue is, that either the "Gitea Data Storage" nor the "Gitea Configuration Storage" get the permissions set at deploy, when Host Path is used. Then the app gets stuck at "deploying" because of permission denied.

I don't like to use the ix-applications dataset, because it is not encrypted and in my own opinion a security risk.

I have no issue with set the permissions by myself at Host Path Volumes, but it would be easier if the needed permissions were to find in the readme or on some other place. I only found out the right permissions with trail and error.

stavros-k commented 8 months ago

The issue is, that either the "Gitea Data Storage" nor the "Gitea Configuration Storage" get the permissions set at deploy, when Host Path is used.

Yes, as explained data dirs are not get their permissions updated when hostPath is used. (postgres directories are currently an exception).

The user/group details required for each app exist as metadata, but I think UI haven't implemented the display of those yet.

toscdesign commented 8 months ago

The user/group details required for each app exist as metadata, but I think UI haven't implemented the display of those yet.

Thank you for the link! But the ids can't be right.

I had to use the 568:568 (apps:apps) on the permissions of the dataset for "Gitea Data Storage" and "Gitea Configuration Storage", to get rid of the permission errors

stavros-k commented 8 months ago

I had to use the 568:568 (apps:apps) on the permissions of the dataset for "Gitea Data Storage" and "Gitea Configuration Storage", to get rid of the permission errors

I've gave it a shot cause this sounded weird, and with 568:568 it wouldn't start for me. Once I used 1000:1000, worked fine.

toscdesign commented 8 months ago

I had to use the 568:568 (apps:apps) on the permissions of the dataset for "Gitea Data Storage" and "Gitea Configuration Storage", to get rid of the permission errors

I've gave it a shot cause this sounded weird, and with 568:568 it wouldn't start for me. Once I used 1000:1000, worked fine.

Here are the permissions, that worked for me: drwxrwxr-x 2 apps apps 3 Jan 2 19:25 config drwxrwxr-x 15 apps apps 15 Jan 2 19:28 data drwx------ 19 netdata docker 26 Jan 3 19:01 db drwxrwxr-x 2 netdata docker 2 Jan 2 18:59 db_backup

I gonna make some tests with the ids 1000:1000 again and report

stavros-k commented 8 months ago

maybe apps user is in a group that has access to user 1000?

stavros-k commented 7 months ago

Hello, closing this for now, if you still having issues, feel free to reply back.

Thanks

Sartoric commented 7 months ago

maybe apps user is in a group that has access to user 1000?

Just adding a comment since I'm facing the same issue and I was looking for a workaround. Actually there is no 1000:1000, at least in a fresh install of Scale 23.10

stavros-k commented 7 months ago

Actually there is no 1000:1000, at least in a fresh install of Scale 23.10

Thats correct, 1000 user is inside the container (its a different set of users than the host) Thats why i used id's and not usernames!