Community Packages

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#73811 - [nextcloud] nextcloud.sock permission denied nginx+uwsgi

Attached to Project: Community Packages
Opened by HLFH (HLFH) - Wednesday, 16 February 2022, 09:27 GMT
Last edited by David Runge (dvzrv) - Wednesday, 16 February 2022, 16:51 GMT
Task Type Bug Report
Category Packages: Testing
Status Closed
Assigned To Sergej Pupykin (sergej)
David Runge (dvzrv)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:

I got the error permission denied on nextcloud.sock, so nginx did not have access to it.

Additional info:
* package version(s): 23.0.2-1

I suggest two things:

1. Have nextcloud.ini in /etc/uwsgi/vassals (like the packages searx-git and searxng-git)

2. Add the 'chmod-socket' line so nginx can read it.
socket = /run/%n/%n.sock
chmod-socket = 666

Nextcloud is a mess with PHP 8.1, the only way to have a working version is to use the version packaged by the great dev David Runge.
This task depends upon

Closed by  David Runge (dvzrv)
Wednesday, 16 February 2022, 16:51 GMT
Reason for closing:  Not a bug
Additional comments about closing:  Please follow the wiki for setting up access rights for the uwsgi socket.
Comment by David Runge (dvzrv) - Wednesday, 16 February 2022, 16:48 GMT
@HLFH: Thanks for the report.

> 1. Have nextcloud.ini in /etc/uwsgi/vassals (like the packages searx-git and searxng-git)

why?

> 2. Add the 'chmod-socket' line so nginx can read it.
> socket = /run/%n/%n.sock
> chmod-socket = 666

That would imply giving write access to nextcloud to *all users* on the system. I would recommend you to look into hardening the uwsgi service [1] and properly managing the socket access [2] instead. Especially the latter is exactly what you want it seems.

[1] https://wiki.archlinux.org/title/UWSGI#Hardening_uWSGI_service
[2] https://wiki.archlinux.org/title/UWSGI#Accessibility_of_uWSGI_socket

Loading...