GRIST did not run anymore

My YunoHost server:

Hardware: Local Debian11 Server
YunoHost version:
I have access to my server : Through SSH and direct access via keyboard / screen

Description of my issue

I have a problem with the Yunohost App GRIST (GetGrist, GRISTLABS). Sorry for posting it here, but there is no App category GRIST available in “Support Apps”-Categoriy (any more).

My GRIST did not start anymore since a few days, there is a permission problem:

Mai 11 16:57:23[439602]: [Error: EACCES: permission denied, mkdir '/home/'] {
Mai 11 16:57:23[439602]:   errno: -13,
Mai 11 16:57:23[439602]:   code: 'EACCES',
Mai 11 16:57:23[439602]:   syscall: 'mkdir',
Mai 11 16:57:23[439602]:   path: '/home/'
Mai 11 16:57:23[439602]: }
Mai 11 16:57:23 systemd[1]: grist.service: Deactivated successfully.

But the file owner looks ok:

root@yuno:/home/ ll
insgesamt 304
-rwx------ 1 grist grist       185 2024-04-09 18:41 custom.env
drwxr-xr-x 2 grist www-data   4096 2024-04-23 18:12 docs
-rw-r--r-- 1 grist www-data 303104 2024-04-23 18:06 home.db
root@yuno:/home/ ll docs
insgesamt 30944
-rw-r--r-- 1 grist grist     1929216 2024-04-23 18:04 5WZ2JMD6GsFS6RHBhuBZV1.grist
-rw-r--r-- 1 grist www-data 13762560 2024-02-21 15:31 b22bNdrsRzThh8wSWk73ww.grist
-rw-r--r-- 1 grist grist      593920 2024-03-04 15:39 jrPY8AgHvwnnfjUXsMxdtp.grist
-rw-r--r-- 1 grist www-data   557056 2024-01-23 11:21 nEVnrNEBJfTBU927P12UFM.grist
-rw-r--r-- 1 grist www-data  1007616 2024-02-13 12:04 rGQXyXBAkKCfw2e78TKCfk.grist
-rw-r--r-- 1 grist grist    13836288 2024-04-14 16:25 sfp3bTTBigogLa7BjvyrpB.grist

What could be the reason for this? How can I solve this?

Can you try running the following command and try again?

sudo chown grist:gris -R /home/


changing also the group to grist didn’t change anything, because grist is just the owner of the files. But I tried it nevertheless - with same error as before.

The most other installed yunohost apps work, but paperless-ngx didn’t start any more, also. And this are the only 2 yunohost-apps which have databases installed in /home/ directory. Other apps works still fine. The /home/ is a symlink to /mnt/srv/ directory which is owned by root (user and group) and has 755 chmod. I wonder if there could be a connection with the installation of adminer, as this was done close to the time when the problems occurred. But I have never opened or modified the databases of grist or paperless-ngx with adminer!

Maybe there is a PHP Problem?
I have php-versions 7.4, 8.0, 8.1, 8.2 and 8.3 installed, because I don’t know, how to find out which version is used (needed) by a yunohost app. How can I get this information for yunohost-Apps? Which version does GRIST use?

As usual in debian 11 the php -v shows, that PHP 7.4.33 (cli) (built: Apr 22 2024 09:38:53) ( NTS ) is the default version. Is this OK? Are there known issues with additional installed php-Versions?

How can I determine which php-modules an app needs? Maybe some needed php modules are not installed?

Or maybe the app did not work with user permissions of user grist?

Where can I get information about the “orchestration” of the Apps? My knowledge about docker container and the orchestration by yunohost are unfortunately very low.

Unfortunately, the diagnosis does not provide any relevant information.

Many thanks for a solution or any ideas.

I managed to make a typo: sudo chown grist:grist -R /home/
Can you check again and restart the service?

Grist does not seem to rely on a database managed by YunoHost (no mention of mysql or postgresql in grist_ynh/manifest.toml at master · YunoHost-Apps/grist_ynh · GitHub). Though Redis is mentioned. Can you check all services run properly?

Grist does not rely on PHP.
Default PHP version on YunoHost 11 is indeed 7.4. YunoHost 12 will be PHP 8.x, but YunoHost should handle multiple versions appropriately, so no worries about that.

All magic happens here, with helper functions documented there.

I saw your typo before and have used correct
chown grist:grist -R /home/ This was not the solution.

In the meantime I checked the following:

  • I tried to change to user grist and tried touch /home/ → file was created as expected.
  • Redis Service is active and running.
  • I searched in /etc/php/7.4/fpm/pool.d and in /etc/php/8.1/fpm/pool.d and /etc/php/8.2/fpm/pool.d for App Configurations. Some other installed apps are there defined like roundcube (php8.1) or signaturepdf (pjp8.2) but there is no conf of grist or paperless-ngx. Doesn’t it mean, that grist and paperless-ngx didn’t run as user but as www-data? This would explain why the service couldn’t start. Or is it possible that fpm is configured elsewhere?
    In /etc/yunohost/apps/grist/scripts/restore i found:

1 #!/bin/bash

21 #=================================================
22 ynh_script_progression --message=“Restoring the app main directory…” --weight=1
24 ynh_restore_file --origin_path=“$install_dir”
26 chown -R $app:www-data “$install_dir”
28 #=================================================
30 #=================================================
31 ynh_script_progression --message=“Restoring the data directory…” --weight=1
33 ynh_restore_file --origin_path=“$data_dir” --not_mandatory
35 # (Same as for install dir)
36 chown -R $app:www-data “$data_dir”

Does this mean that the service is running as www-data - not as user grist.?

Should I try to start this restore-script or manually
chown grist:www-data -R /home/
But this settings was not modified. In an old (working) copy of my installation the group of some database files in grist/docs was www-data in some it was grist (as the owner of all files).

What could be the commonality between grist and paperless-ngx that explains why both services no longer work?

Thank you for your support!

Grist and Paperless NGX do not rely on PHP, they provide their own webservers and NGINX reverse proxy them.

Yeah let’s try that :slight_smile: I am trying to find some resource to test the app myself, but so far my servers run out of memory. :sweat:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.