Specifically XLSX files are not being saved.

[z0rgster]

Hi,

I have a strange problem with my OnlyOffice installation. This exists since many months and across different versions and is browser-independent. I hope that someone can point me in the right direction.

My situation:

I run Docker Swarm on Photon OS with a Nextcloud stack including OnlyOffice and other containers behind a Traefik reverse proxy. The files are located on my Nextcloud instance. I used external shares in the past but now everything is located on local storage owned by the Nextcloud instance. I am running onlyoffice/documentserver:7.1.1 and use the latest OnlyOffice Nextcloud Integration (7.4.2). When I open a presentation (pptx), document (docx) or form (docx), the changes are saved as expected. Meaning 10s after leaving the document or when pressing ctrl+s in the editor. The option force save is activated. So far so good.

BUT when I open any spreadsheet (xlsx), I suddenly can't save my changes. The status bar tells me "All chages were saved" but after closing the tab and waiting for 10s, the changes are missing although the file change date was actually updated. If I edit the file on my device with MS Excel, the changes are synced to the Nextcloud and can be displayed by OnlyOffice. When I saved the edited xlsx file as ods, the changes were written to my Nextcloud without any problems. But saving as ods is no option. So literally everything is working, just saving xlsx from the OnlyOffice editor won't work. This is the case for both new and existing spreadsheets. I then activated und tried the builtin test environment with docker exec <container-id> sudo supervisorctl start ds:example but even there the problem persisted.

The forced saving of the spreadsheet is accompanied by the following error message when viewing the logs of the documentserver container:

==> /var/log/onlyoffice/documentserver/converter/out.log <==
[2022-06-20T12:12:06.827] [ERROR] nodeJS - stdout (id=1295780845_1972):
[2022-06-20T12:12:06.827] [ERROR] nodeJS - stderr (id=1295780845_1972):Uncaught TypeError: Cannot read property 'Tf' of null
DoctRenderer:<result><error index="2" /></result>
Uncaught TypeError: Cannot read property 'Tf' of null
DoctRenderer:<result><error index="1" /></result>
Uncaught TypeError: Cannot read property 'Tf' of null
DoctRenderer:<result><error index="0" /></result>
[2022-06-20T12:12:06.827] [ERROR] nodeJS - ExitCode (code=86;signal=null;error:-86;id=1295780845_1972)

In prior tests the messages contained Cannot read property 'Dra' of null but I suppose that the problem is rather the null object than the property name.

Does anyone have an explanation for this behaviour? So far this seems not to be an issue with Nextcloud or the OnlyOffice integration app but with the documentserver itself. Can this be caused by bad headers? I had some issues with setting the correct headers in the Traefik configuration. Any help is greatly appreciated.

[ShockwaveNN]

Hi

I then activated und tried the builtin test environment with docker exec sudo supervisorctl start ds:example but even there the problem persisted.

Nice that you've done it, since we can totally rule out nextcloud from your setup and try to localize your problem without it

I think there is may be some problem in configuration with Traefic because it sometimes cause very strange problems and this problem is indeed very strange (especially part that only Spreadsheet got in troubles

[2022-06-20T12:12:06.827] [ERROR] nodeJS - stderr (id=1295780845_1972):Uncaught TypeError: Cannot read property 'Tf' of null

Those errors mean that something is wrong with saving this file from our internal format but I cannot guess what is wrong with it by this error

I think next stop for us will be to rule out Traefik - you should try to setup just a docker instance on some of your server, for example simplest way will be

docker run -itd -p 80:80 onlyoffice/documentserver

and check that Spreadsheet saving fine using ds:example (without Nextcloud) If this fail also this may be some problem we didn't guessed, if this will not fail - probably problem in Traefik setup

[z0rgster]

Sorry, I didn't mean to close this yet ...

[z0rgster]

I mixed up the buttons. Here's my original message: Hi, thanks for the reply! I will first try and simply connect to the existing container via local network and if that fails as well, I will recreate an "isolated" container like you described.

[z0rgster]

After my last message I tried the local connection and the saving process seemed to be working with a local connection while the web connection did not work. After clearing all OnlyOffice volumes I now experienced the same issues with a local connection. Finally I got the time to do some structured testing. I first tested the local connection and and didn't even bother to do it again with the web connection as even locally nothing worked.

After setting up a separate OnlyOffice-Stack, everything worked as expected. The main difference was that I didn't assign any volumes. After removing that section from the Nextcloud stack, that version did work as well. That way I identified the fonts volume as the cause of the problems. I deleted all custom fonts but the problem persisted. That meant that the fonts themselves weren't the real problem. Turns out that I didn't have the right owner for the "_data" directory in the volume. It was root:root somehow, but OnlyOffice expects 109:112 instead. I restored the deleted fonts and set the owner to 109:112 with permissions 755. After updating the OnlyOffice service it finally worked!

Conclusion: I gave myself a very hard time when I screwed up those directory permissions some months ago. So if you experience such strange issues with any docker application, always check your volume owners and permissions. Still, I wonder how it can be that the file permissions can have such a different impact on the functionality of the OnlyOffice components. Maybe that could be a topic that the OnlyOffice devs can have a look at. For future idiots like me, an error message for incorrect permissions might be helpful :)

[ShockwaveNN]

That way I identified the fonts volume as the cause of the problems.

Could you clarify how you mount font volume?

And I think if there is some permission problem - there are some errors in startup logs, especially on this step

Generating AllFonts.js, please wait...Done

[z0rgster]

This is basically my compose-file. I just omitted the traefik labels.

services:
  # nextcloud and other services
  office:
    image: onlyoffice/documentserver:7.1.1
    networks:
      - nextcloud
    volumes:
      - office-cert:/var/www/onlyoffice/Data
      - office-logs:/var/log/onlyoffice
      - office-cache:/var/lib/onlyoffice
      - office-font:/usr/share/fonts/truetype/custom
      - office-db:/var/lib/postgresql
    deploy:
      labels:
        # traefik stuff
  # more services

I closely monitored the logs but at the GenerateAllFonts step everything looked normal. This was my output:

 * Starting PostgreSQL 12 database server
   ...done.
 * Starting RabbitMQ Messaging Server rabbitmq-server
   ...done.
Starting supervisor: supervisord.
 * Starting periodic command scheduler cron
   ...done.
 * Starting nginx nginx
   ...done.
Generating AllFonts.js, please wait...Done
Generating presentation themes, please wait...Done
ds:docservice: stopped
ds:docservice: started
ds:converter: stopped
ds:converter: started
 * Reloading nginx configuration nginx
   ...done.

[ShockwaveNN]

Any chance you can provide step-by-step intruction with how you've created your volume so it causes problem with DocumentServer

I've tried to make some fonts with incorrect permission, owned by non-existing users buy everything sill works fine for me

[z0rgster]

I think at some point I manually messed up the volume permissions with a chown root:root on the volumes directory or some dangerous stuff like that. I guess I did that when I migrated to a new server.

Steps to reproduce would be:

1. Create and start the stack/container and assign volumes as defined in https://github.com/ONLYOFFICE/DocumentServer/issues/1817#issuecomment-1181793891 (I used "Nextcloud" as stack name)
2. Stop the stack/container
3. Open shell on host as root
4. Navigate to /var/lib/docker/volumes/
5. Check out permissions of ./nextcloud_office-font
6. It should be root:root and 755 at this level.
7. Check out permissions of ./nextcloud_office-font/_data
8. It should be 109:112 and 755 at this level.
9. Execute chown -R root:root /var/lib/docker/volumes/nextcloud_office-font
10. Now the permissions of the _data directory were overwritten.
11. Start the stack/container

[z0rgster]

Could you reproduce the behaviour with the steps I provided?

[ShockwaveNN]

Could you reproduce the behaviour with the steps I provided?

Sorry, I've not got any free time to check it, I'll comment as soon as I am able to

[z0rgster]

No problem I know that situation too well.

[ShockwaveNN]

Hi, back to your problem

Could you specify how did you've created office-font volume and if this volume has any data (I think it has) on first docker compose up run (Step 1 in here)?

[z0rgster]

The volume was automatically created by docker inside the /var/lib/docker/volumes/ directory as /var/lib/docker/volumes/nextcloud_office-font because I specified the volume in the volumes section of the compose file (not shown here). In there a directory _data is automatically created as well. The compose file is managed by portainer, which launches it via docker stack deploy.

Normally the nextcloud_office-fontdirectory is owned and accessible by the root user and the _datadirectory inside is owned and accessible by the image-specific user which could be (but wasn't) altered by the GID and UID environment variables.

In the beginning there was no data inside. I copied the files in there via WinSCP.

I noticed that I got the directory in my step-by-step description wrong. I will edit it after posting this.

[ShockwaveNN]

Ok, got it, I forgot to specify volumes at end of my dockerfile

But something seems not like on your system for me:

1. I created such docker-compose.yml

services:
  office:
    image: onlyoffice/documentserver:7.1.1
    volumes:
      - office-font:/usr/share/fonts/truetype/custom
volumes:
  office-font:

2. Started that compose and spopeed it after it
3. Go to /var/lib/docker/volumes/office-font/ and checking out permissions:

They are not like you've mentioned:

It should be 109:112 and 755 at this level.

[Rita-Bubnova]

This issue was closed due no response.