YunoHost 4.2 testing

Well so far they were only used in specific case (e.g. the multimedia folders)

But that sounded like an easy and elegant solution to the security issues spotted recently … but of course it sounds like nothing is never that easy with computers …

Naively I’d think on any regular setup with ext4 filesystem, ACL should just work …

1 Like

I’ll maybe look deeper into it, but QNAP kernel seems to really implement sh*tty ACL if this old post is still true…
EDIT: Unfortunately, looking at the latest QNAP kernel source code, the “custom” ACL algorithm hasn’t changed since that aforementioned forum post… In my case above, any --- entry in the ACL list (which is the very case in that 4.2.1 fix) denies access to all :sweat:

I still have the issue with services with 4.2.1. (I don’t know if this version was supposed to address this issue…).
I also get an error while closing ports…

@ericg : no it did not, but as we discussed on the chat, considering that there are several important small bugs with fixes pending, I’m making an hotfix release in before the next big iteration:

  • [fix], python3: missing decode() in subprocess output fetch (357c151c)
  • [fix] don’t inject log_ref if the operation didnt start yet (f878d61f)
  • [fix] Missing raw_msg=True (008e9f1d)
  • [fix] Don’t miserably crash when there are port ranges (6fd5f7e8)
  • [fix] nginx conf: CSP rules for admin was blocking small images used for checkboxes, radio, pacman in the new webadmin (575fab8a)

Builds are ongoing, should be available in a couple minutes :+1:


A post was split to a new topic: Yunohost on Ubuntu

And here’s another big iteration on both the core and the new webadmin !


  • :sparkles: UI/UX fixes and improvements in the new webadmin thanks to the feedback of the testers :love_letter:. This include new human-readable descriptions of what’s going on each time an operation is triggered.
  • :key: SFTP and SSH permissions. This will allow to grant SSH/SFTP access to users using the permission system. This also comes with a rework of the SSH configuration. Note that, by design, you can’t grant this permission to all users. You must grant it to individual users, or create a group and grant the permission to this group. We also recommend to be careful and not grant this permission to random people that you don’t really trust.
  • :ambulance: Many improvements on backups, including a significant rework of the content of system backups which should now be more sensible and prevent inconsistencies.

Thanks to all contributors :heart: ! (axolotle, Bram, C. Wehrli, cyxae, D. Vasilev, Daniel, Éric G., grenagit, Josué, Kay0u, K. Nowakowski, lapineige, ljf, Scapharnaum)

Detailed changelog

  • permissions: Add SFTP / SSH permissions (#606, Yunohost-admin#352)
  • webadmin ux: Human readable operation names (Yunohost-admin#339)
  • refactoring: Uniformize / more consistent API routes (#1192, Yunohost-admin#339, Yunohost-admin#350)
  • webadmin ux: At the end of an operation, display a modal if last message is a warning (#347)
  • webadmin, postinstall: Handle validation errors and force-diskspace option (#349)
  • settings: New setting to disable the ‘YunoHost’ panel overlay in apps (#1071, 08fbfa2e)
  • settings: New setting for custom ssh port (#1209, 37c0825e, 95999fea)
  • security: Redact ‘passphrase’ settings from logs (#1206)
  • security: Sane default permissions for files added using ynh_add_config and ynh_setup_source (#1188)
  • backup: Support having .tar / .tar.gz in the archive name arg of backup_info/restore (00ec7b2f)
  • backup: Don’t backup crons + manage crons from the regenconf (#1184)
  • backup: Drop support for archive restore from prior 3.8 (#1203)
  • backup: Introduce hooks during restore to apply migrations between archive version and current version (#1203)
  • backup: Create a proper operation log for backup_create (fe9f0731)
  • backup: Improve error management for app restore (#1191)
  • backup: Rework content of system backups (#1185)
  • backup: Add a --dry-run option to backup_create to fetch an estimate of the backup size (#1205)
  • helpers: Add --keep option to ynh_setup_source to keep files that may be overwritten during upgrade (#1200)
  • helpers: Bump ‘n’ to version 7.1.0 (#1197)
  • mail: Support SMTPS Relay (#1159)
  • nginx: add header to disallow FLoC (#1211)
  • custom apps install: Add route to fetch app manifest in a forge-agnostic way (#1213, Yunohost-admin#351)
  • perf: add optional ‘apps’ argument to user_permission_list to speed up user_info / user_list (e6312db3)
  • ux: Add ‘–human-readable’ to recommended command to display diagnosis issues in cli (#1207)
  • ssowat: Remove SSOwAuthRedirect (SSOwat#182)
  • ssowat: Avoid a syscall for cookies (SSOwat#183)
  • Misc enh/fixes, code quality (42f8c9dc, 86f22d1b, 1468073f, b33e7c16, d1f0064b, c3754dd6, 02a30125, aabe5f19, ce9f6b3d, d7786662, f9419c96, c92e495b, 0616d632, 92eb9704, #1190, #1201, #1210, #1214, #1215, Yunohost-admin#344, Yunohost-admin#348)
  • i18n: Translations updated for French, German, Italian, Polish, Portuguese, Russian, Spanish

Annnnnd the usual “bug I noticed after releasing” : for some reasons all my backup archives containing only apps are displayed as empty (but pretty sure they are not). Will investigate later.

1 Like


Upgrading to 4.2.2 testing version solve the problem of “blank app”.
Thanks to the team <3



If it could helps :

Raspberry Pi 3 B YunoHost 4.2.2 testing and the zwiicms is a working unofficial packaging test.

WARNING - /var/cache/yunohost/app_tmp_work_dirs/app_hg9ig_0w/scripts/backup: line 62: phpversion: unbound variable

Show / hide

2021-04-17 08:10:29,729: DEBUG - + dest_path=apps/zwiicms/backup/etc/nginx/conf.d/
2021-04-17 08:10:29,730: DEBUG - ++ sed --regexp-extended ‘s/"/""/g’
2021-04-17 08:10:29,730: DEBUG - ++ echo /etc/nginx/conf.d/
2021-04-17 08:10:29,737: DEBUG - + local src=/etc/nginx/conf.d/
2021-04-17 08:10:29,738: DEBUG - ++ sed --regexp-extended ‘s/"/""/g’
2021-04-17 08:10:29,739: DEBUG - ++ echo apps/zwiicms/backup/etc/nginx/conf.d/
2021-04-17 08:10:29,743: DEBUG - + local dest=apps/zwiicms/backup/etc/nginx/conf.d/
2021-04-17 08:10:29,744: DEBUG - + echo '"/etc/nginx/conf.d/","apps/zwiicms/backup/etc/nginx/conf.d/"’
2021-04-17 08:10:29,745: DEBUG - ++ dirname /home/yunohost.backup/tmp/20210417-060947/apps/zwiicms/backup/etc/nginx/conf.d/
2021-04-17 08:10:29,758: DEBUG - + mkdir --parents /home/yunohost.backup/tmp/20210417-060947/apps/zwiicms/backup/etc/nginx/conf.d/***
2021-04-17 08:10:29,767: WARNING - /var/cache/yunohost/app_tmp_work_dirs/app_hg9ig_0w/scripts/backup: line 62: phpversion: unbound variable
2021-04-17 08:10:29,769: DEBUG - ++ ynh_exit_properly
2021-04-17 08:10:29,770: DEBUG - ++ local exit_code=1
2021-04-17 08:10:29,771: DEBUG - ++ rm -rf /var/cache/yunohost/download/
2021-04-17 08:10:29,771: DEBUG - ++ ‘[’ 1 -eq 0 ‘]’
2021-04-17 08:10:29,771: DEBUG - ++ trap ‘’ EXIT
2021-04-17 08:10:29,772: DEBUG - ++ set +o errexit
2021-04-17 08:10:29,773: DEBUG - ++ set +o nounset
2021-04-17 08:10:29,773: DEBUG - ++ sleep 0.5
2021-04-17 08:10:30,277: ERROR - Impossible de sauvegarder zwiicms
2021-04-17 08:10:32,957: INFO - Création d’une archive de sauvegarde à partir des fichiers collectés…
2021-04-17 08:10:32,960: INFO - The archive will contain about 375.1MiB of data.
2021-04-17 08:10:32,963: DEBUG - Création de l’archive TAR de la sauvegarde…
2021-04-17 08:12:41,375: DEBUG - L’archive TAR de la sauvegarde a été créée
2021-04-17 08:12:41,377: SUCCESS - Sauvegarde terminée


After updating I got this weird error:

Yunohost API could not find a route

Really sorry about that.

You should look for help on the forum or the chat to fix the situation, or report the bug on the bugtracker.
The following information might be useful for the person helping you:

Error: "404" Not Found

Action: "PUT" /yunohost/api/update

Error message: Seems like the web-admin tryed to query something that doesn’t exist.

@TheNomad11 : sounds like some temporary issue because of changes in the API … do you still have the issue after the update actually finishes ?

Même problème une heure après mise à jour de 4.2.2.
Les entrées Utilisateurs / Domaines / Applications / Services / Diagnostic et Sauvegardes ne fonctionnent plus.
Le menu “Outils” fonctionne.
“Mettre à jour” s’affiche, mais renvoie cette erreur.

Même symptomes après reboot.
sudo yunohost tools update renvoie que tout est à jour.

Eeeh okay, et en forcant le rafraichissement du cache navigateur avec Ctrl+Shift+R ?

:+1: Tout retombe en marche !

The upgrade went well on my side (except my permanent ACL problems above, for which I need to manually revert the ACLs’ after each regen-conf).

I was using a legacy linux user (not a YunoHost user) to log to SSH with a private key. I can’t log any more. In my understanding, it’s because it’s not part of the “ssh.main” group. But, I can’t add the user to the group with usermod -a -G ssh.main <myuser>.
How is it and what’s my best way to address the problem? Add that user to the group by another way? Somehow “convert” it to a YunoHost user, but then how to log with a private key and add it to the sudo group?

Upgraded to 4.2.2. Admin page wasn’t working, but that eventually cleared when I shutdown and restarted my browser.

However, I’m having the SSH problem, too. I was using a Linux account with an RSA key. Now it’s asking for password, but the password is not being accepted. Thus, I can’t log onto the box to investigate or fix. Suggestions?

You are right. Everything fine now. I had waited more than ten minutes, though

For this, I suggest adding a custom regen conf hook (should me named xx-yunohost_whatever, but the yunohost_ is the important part)

c.f. discussion in Configuration custom - aide pour création de hooks

I think in your case that’d look like:


[[ $action == "post" ]] || exit 0

# here, add your ACL commands

Zblerg yeah now you need to be in the ssh.main group. Or you can also add it to the admins group, that would work too.

But ideally it should indeed be converted to a regular yunohost user (if that makes sense).

Then to log using a private key, just add the key in the authorized_keys just like you would usually do. And you can usernmod -a -G sudo <the user> just like you would with any regular users I think ?

1 Like

c.f. answer to JimboJoe, you can maybe add that user to the admins group. Or ideally recreate the user as a yunohost user if that makes sense (or add your RSA key to an existing yunohoser user and use that one from now on). In the meantime, you should still be able to log in as admin/root to fix the issue.

:warning: Important : we noticed that the webadmin update from tonight included some forgotten debug code that disabled some features such as upgrading. As a consequence, when you click the “Upgrade” button, no upgrade will actually be performed… The workaround is to upgrade from the command line with yunohost tools upgrade --system for this time.

The fix has been released in Yunohost-admin

(N.B.: This is only relevant if you upgraded today)

1 Like