Most (or all) packages run something like this:
chown -R $app:www-data "$install_dir"
chown -R $app: "$data_dir"
In /scripts/restore after calling ynh_restore…
Why is this needed? Should ynh_restore not result in correct permissions for extracted items and the parent directory?
This should be “fixed” in helpers 2.1, yes
Really? I migrate to them and hat still problems around this.
Think it’s the problem with the parent directory permission after restore.
Then if you “still have the problem” you should share the corresponding logs, we can’t magically guess why it’s needed without having not even the name of the app …
Currently i call often my helper:
myynh_fix_file_permissions() {
# /var/www/$app/
# static files served by nginx, so use www-data group:
chown -c -R "$app:www-data" "$install_dir"
chmod -c u+rwx,g+rx,o-rwx "$install_dir"
# /home/yunohost.app/$app/
chown -c -R "$app:$app" "$data_dir"
chmod -c u+rwx,g+rwx,o-rwx "$data_dir"
}
I will try to investigate this, if i found time 
For packages using helpers <=2.0, you need to do this chown cause we don’t detect in which scenario we are restoring things.
For example, if you restore on a new system (or an other system) typically a migration or a complete restore after a total crash, users ids could be differents… So it’s not enough to untar (or borg extract…), cause the files after this could be binded to an other user (who have the id of the owner on the previous system).
In an other scenario, typically restoring just one app on the same system, just after deleted this app (typically an upgrade crash), it should not be needed.
I’m on 2.1…
I created a test now: Remove chown/chmod calls by jedie · Pull Request #78 · YunoHost-Apps/django-for-runners_ynh · GitHub
It’s done: YunoRunner for CI and restore failed:
11082 + ls -la /home/yunohost.app
11083 total 16
11083 drwxr-xr-x 4 root root 4096 Sep 8 09:31 .
11084 drwxr-xr-x 6 root root 4096 Aug 16 22:19 ..
11084 dr-------- 4 root root 4096 Sep 8 09:31 django-for-runners
11084 drwxr-xr-x 2 root root 4096 Sep 8 09:19 witnessdir
11084 + ls -la /home/yunohost.app/django-for-runners
11087 total 144
11087 dr-------- 4 root root 4096 Sep 8 09:31 .
11087 drwxr-xr-x 4 root root 4096 Sep 8 09:31 ..
11087 drwxr-xr-x 6 django-for-runners django-for-runners 4096 Sep 8 09:21 .venv
11087 drwxr-xr-x 2 root root 4096 Sep 8 09:21 __pycache__
11088 -rw------- 1 django-for-runners django-for-runners 629 Sep 8 09:21 gunicorn.conf.py
11088 -rw-r--r-- 1 django-for-runners django-for-runners 4 Sep 8 09:31 gunicorn.pid
11088 -rwxr-xr-x 1 root root 13758 Sep 8 09:21 install_python.py
11088 -rw-r--r-- 1 root root 0 Sep 8 09:21 local_settings.py
11088 -rwx--x--x 1 django-for-runners django-for-runners 293 Sep 8 09:21 manage.py
11088 -rw-r--r-- 1 root root 76147 Sep 8 09:21 requirements.txt
11088 -rw-r--r-- 1 root root 171 Sep 8 09:21 secret.txt
11088 -rw------- 1 django-for-runners django-for-runners 6117 Sep 8 09:21 settings.py
11088 -rw------- 1 django-for-runners django-for-runners 263 Sep 8 09:21 setup_user.py
11088 -rw------- 1 django-for-runners django-for-runners 867 Sep 8 09:21 urls.py
11088 -rw------- 1 django-for-runners django-for-runners 184 Sep 8 09:21 wsgi.py
...
11543 + ynh_exec_as_app /usr/bin/python3.11 -m venv --clear --upgrade-deps /home/yunohost.app/django-for-runners/.venv
11544 + sudo --preserve-env=PATH -u django-for-runners /usr/bin/python3.11 -m venv --clear --upgrade-deps /home/yunohost.app/django-for-runners/.venv
11596 Error: [Errno 13] Permission denied: '/home/yunohost.app/django-for-runners/.venv'
Think the reason is, that /home/yunohost.app/django-for-runners has wrong permissions:
dr-------- 4 root root 4096 Sep 8 09:31 django-for-runners
isn’t it?
Oh, interesting. Now i see:
So, ynh_restore "$install_dir" (/var/www/$app/) has correct permissions, only
ynh_restore "$data_dir" (/home/yunohost.app/$app/) has wrong one.
Is this just a bug?
Supposedly fixed in 11.2.30.2
