Document server fails with "./x2t: Permission denied"

[Xeyk]

Hey, all. I have updated my Nextcloud instance from 16 to 18. I uninstalled the OnlyOffice app, then reinstalled it. After doing that, I installed the Community Document Server app. Whenever I click on a .doc or .docx file, I get the error stated in the subject.

Please let me know if you need me to pull any logs and I will gladly do so.

[anatomism]

For those on CentOS 7 / SELinux, do this first: #10 (comment)

... then, in nextcloud/apps/documentserver_community/3rdparty/onlyoffice/documentserver/server/FileConverter/bin/

chcon --type httpd_sys_script_exec_t *.so.58 chcon --type httpd_sys_script_exec_t *.so

This worked for me when trying to view on mobile app, however as with the above (and comment 10) I had to also include the binary, x2t, so the following was done for me to make it work

cd <nextcloud_root_folder>/apps/documentserver_community/3rdparty/onlyoffice/documentserver/server/FileConverter/bin/

chmod u+x docbuilder x2t setsebool -P httpd_unified 1 ausearch -c 'x2t' --raw | audit2allow -M my-x2t semodule -i my-x2t.pp

chcon --type httpd_sys_script_exec_t *.so.58 chcon --type httpd_sys_script_exec_t *.so chcon --type httpd_sys_script_exec_t x2t

My install is CentOS 7 latest with SELinux enabled

I also have an install with CentOS 8 and I haven't had to do the latter part of the above as far as I can remember, seems to be an issue with CentOS 7 only

[NoxInmortus]

Hello, there seems to be no reports from Nextcloud or DocumentServer staff here about the resolution of this issue. Does it progress in any way?

[skjnldsv]

Please also remember that the files needs to be owned by the html user (www-data usually, adjust to your setup)

[siccovansas]

For those who use an alpine Nextcloud image in their docker compose (which I had because Nextcloud uses alpine in their docker compose example code), you can switch to using the non-alpine Nextcloud image. That way I got Onlyoffice to work.

As always, make sure you have backups!

• Remove the -alpine part from the nextcloud service in your docker-compose.yml (also remove alpine versions from containers that mount your nextcloud folder, like cron and web/nginx containers, and rebuild them)
• Run docker-compose pull
• Run docker-compose up -d
• Change ownership permissions as alpine uses a different user id (change nextcloud_app_1 to your container name if it is different): docker exec nextcloud_app_1 chown -R www-data:root /var/www
• You might need to do a docker-compose restart and/or reinstall the community document server and ONLYOFFICE apps

[gfiasco]

I have tried everything in here but nothing seem to work around this

I'm using nextcloud:stable with mysql as db.

even fresh installation suffers of this

[oucil]

setsebool -P httpd_unified 1

If anyone read this above with reference to CentOS and is serious about using SELinux properly, DO NOT do this, as it essentially tells SELinux to stop enforcing anything for httpd effectively giving it all permissions for any resources assigned to the Apache user. Do a little more work and figure out what specific contexts / boolean permissions you need and enable them, and only them. If you're using php_fpm, you can further isolate your permissions using sub-contexts, and different apache child users.

[zynexiz]

As stated above, don't disable selniux to enforce it's policy's. I just had the same problem and solved it by adding a policy to selinux. The sever needs to execute the binary, so instead add the following (might have to change the path to your installation folder) for CentOS;

semanage fcontext -a -t httpd_sys_script_exec_t '/var/www/html/nextcloud/apps/documentserver_community/3rdparty/onlyoffice/documentserver(/.*)?'
restorecon -R -v /var/www/html/nextcloud

[yardbro]

Old thread but to anyone still experiencing this issue, ensure that you use -R when applying chown (chown -R www-data:www-data documentserver_community/) if you installed the Community Document Server app manually. I had this exact issue and realized that I had only been changing ownership of the main directory, not the sub-directories. Hope this helps someone

[deajan]

For whoever might be concerned about the more recent problems with x2t and onlyoffice, eg OCA\DocumentServer\Document\DocumentConversionException: ./x2t: error while loading shared libraries: libgraphics.so: cannot open shared object file: No such file or directory

Check if your problem is SELinux related, eg disable selinux with setenforce 0 and try again. If so, re-enable selinux with setenforce 1 and proceed to create the following Selinux policy:

Create file /root/my-onlyoffice.te containing

module my-onlyoffice 1.0;

require {
        type httpd_sys_script_exec_t;
        type httpd_t;
        type ld_so_t;
        type configfs_t;
        class file { execute_no_trans setattr };
        class dir { getattr };
}

#============= httpd_sys_script_exec_t ==============
allow httpd_t httpd_sys_script_exec_t:file setattr;
allow httpd_t ld_so_t:file execute_no_trans;
allow httpd_t configfs_t:dir getattr;

Now proceed to create a module from that file with command

checkmodule -M -m -o /root/my-onlyoffice.mod /root/my-onlyoffice.te

Now create a selinux loadable policy

semodule_package -o /root/my-onlyoffice.pp -m /root/my-onlyoffice.mod

Load the policy with cd /root && semodule -i my-onlyoffice.pp

Now it's time to label your nextcloud + onlyoffice setup (of course, adapt paths to your virtualhost)

# php specific session, tmp and opcache dirs
semanage fcontext -a -t httpd_sys_rw_content_t '/var/www/nextcloud/tmp(/.*)?'
semanage fcontext -a -t httpd_sys_rw_content_t '/var/www/nextcloud/sessions(/.*)?'
semanage fcontext -a -t httpd_sys_rw_content_t '/var/www/nextcloud/opcache(/.*)?'
# nextcloud data dir
semanage fcontext -a -t httpd_sys_rw_content_t '/data(/.*)?'
# nextcloud app
semanage fcontext -a -t httpd_sys_rw_content_t '/var/www/nextcloud/ftp/www/config(/.*)?'
semanage fcontext -a -t httpd_sys_rw_content_t '/var/www/nextcloud/ftp/www/apps(/.*)?'
semanage fcontext -a -t httpd_sys_rw_content_t '/var/www/nextcloud/ftp/www/.htaccess'
semanage fcontext -a -t httpd_sys_rw_content_t '/var/www/nextcloud/ftp/www/.user.ini'
semanage fcontext -a -t httpd_sys_rw_content_t '/var/www/nextcloud/ftp/www/3rdparty/aws/aws-sdk-php/src/data/logs(/.*)?'
# onlyoffice specific
semanage fcontext -a -t httpd_sys_script_exec_t '/var/www/nextcloud/ftp/www/apps/documentserver_community/3rdparty/onlyoffice/documentserver(/.*)?'
semanage fcontext -a -t ld_so_t '/var/www/nextcloud/ftp/www/apps/documentserver_community/3rdparty/onlyoffice/documentserver/server/FileConverter/bin/.*\.so.*'
# apply above contexts
restorecon -Rv '/var/www/nextcloud/'
restorecon -Rv '/data'

Should work ;)

[Wotisrv]

I was running OnlyOffice fine since it was included in Nextcloud 19. I needed to adjust the SELinux permissions as described here to get it work. Now for a couple of days I figured out that I got back the x2t permission denied error. The solution from @deajan fixed the error. Furthermore I needed to issue chmod u+x docbuilder since this one lost its permissions. After all that, I can run OnlyOffice inside Nextcloud but with the mobile app I got still x2t permission denied error. Everything works fine with disabled SELinux. I upgraded also to Nextcloud 20.0.2 today, but permission error using mobile app still continues. No log in SELinux about blocking but in Nextcloud.

System Fedora-Server 32 Edition, Nextcloud 20.0.2

[AndreasDekiert]

Even after applying @deajan 's SELinux module and contexts I still cannot get OnlyOffice to run. Checking the SELinux audits with ausearch -c 'x2t' I get several results like the following:
type=ANOM_ABEND msg=audit(1615135507.682:588047): audit=982 uid=982 gid=975 ses=82515 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=18453 comm="x2t" reason="memory violation" sig=4

Creating a custom SELinux module with audit2allow is not possible for this "memory violation". Any ideas?

System CentOS 7, Nextcloud 20.0.8

[Wotisrv]

I applied @deajan SELinux module and I get now: "SELinux prevents php-fpm from accessing sock_file clamd.sock with write access." type=AVC msg=audit(1615235215.940:543): avc: denied { write } for pid=1097 comm="php-fpm" name="clamd.sock" dev="tmpfs" ino=1812 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:antivirus_var_run_t:s0 tclass=sock_file permissive=0

I do not understand why php-fpm should get write access to clamd.sock file? The SELinux policy allow antivirus to can scan system is activated: boolean -m -1 antivirus_can_scan_system

System Fedora 33 Server-Edition, Nextcloud 20.0.8

[deajan]

@Wotisrv Looks like you have the antivirus plugin in Nextcloud where nextcloud itself triggers an AV scan. Can you confirm ?

[Wotisrv]

@deajan yes that's right.

[homosco]

On our server (managed by the provider) the same issue comes up (since yesterday). Error messages: "Community document server is not supported for this instance, please setup and configure an external document server✖" and: "can't execute x2t binary, ensure php can execute binaries in the app folder✖" Running Nextcloud 21.0.1 Reinstalling both Apps didn't resolve the issue.

Since I have no admin access to the server itself i can't provide much more information. The provider claims it gives no support for the App but tells me, that other customers experience the same issue.

Bottonline: Issue is still unresolved and comes up under Nexcloud 21 as well.

[sich97]

Yeah I just got this error as well. I've read about the "chmod u+x docbuilder" solution, but I don't have a file path which corresponds to the where I'm supposed to run that command. Under "/apps/documentserver_community/3rdparty/onlyoffice/documentserver/", I only have a folder called "web-apps". This should be looked into more, since this was a fresh install. I installed nextcloud manually (not docker), but I installed OnlyOffice and Community Document Server through Nexctloud's App menu. So if I'm missing any dependencies then at least I should have been informed of such in the documentation or after setup. But of course the best thing would be if the app itself was plug and play.

[sitoexpress]

Same issue here