Change:
add_header X-Permitted-Cross-Domain-Policies none; add_header X-Frame-Options sameorigin; add_header Referrer-Policy no-referrer; <del> add_header Strict-Transport-Security "max-age=15552000; includeSubDomains" always; error_page 403 /core/templates/403.php; error_page 404 /core/templates/404.php; client_max_body_size ${cfg.maxUploadSize}; fastcgi_buffers 64 4K; fastcgi_hide_header X-Powered-By; gzip on; gzip_vary on; gzip_comp_level 4; gzip_min_length 256; gzip_proxied expired no-cache no-store private no_last_modified no_etag auth; gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/vnd.ms-fontobject application/x-font-ttf application/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/bmp image/svg+xml image/x-icon text/cache-manifest text/css text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy; ${optionalString cfg.webfinger '' rewrite ^/.well-known/host-meta /public.php?service=host-meta last; rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json last; ''} </del> <ins> access_log off; ''; "~ .(?:png|html|ttf|ico|jpg|jpeg|bcmap|mp4|webm)$".extraConfig = '' try_files $uri /index.php$request_uri; access_log off; </ins> ''; }; <ins> extraConfig = '' add_header X-Content-Type-Options nosniff; add_header X-XSS-Protection "1; mode=block"; add_header X-Robots-Tag none; add_header X-Download-Options noopen; add_header X-Permitted-Cross-Domain-Policies none; add_header X-Frame-Options sameorigin; add_header Referrer-Policy no-referrer; add_header Strict-Transport-Security "max-age=15552000; includeSubDomains" always; error_page 403 /core/templates/403.php; error_page 404 /core/templates/404.php; client_max_body_size ${cfg.maxUploadSize}; fastcgi_buffers 64 4K; fastcgi_hide_header X-Powered-By; gzip on; gzip_vary on; gzip_comp_level 4; gzip_min_length 256; gzip_proxied expired no-cache no-store private no_last_modified no_etag auth; gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/vnd.ms-fontobject application/x-font-ttf application/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/bmp image/svg+xml image/x-icon text/cache-manifest text/css text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy; ${optionalString cfg.webfinger '' rewrite ^/.well-known/host-meta /public.php?service=host-meta last; rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json last; ''} ''; </ins> }; }; <del> }) </del> <ins> } </ins> ]); meta.doc = ./nextcloud.xml;

Discussion:
Describe the bug When deploying a nextcloud service, if nginx is not enabled, the unit scripts of php-fpm and nextcloud-setup systemd services fail. This makes it more difficult than necessary to use nextcloud with a different web server. For both services, the issue is caused by hardcoding the nginx user and/or group in the unit scripts. For the php-fpm service, we see nginx hardcoded in a . For nextcloud-setup, the failure is related to , where the nginx group is hardcoded into this chown command. The resulting error message: To Reproduce Steps to reproduce the behavior: the service, and add the systemd service as described in the , but with the option set to false. Expected behavior Not enabling nginx should still allow nextcloud to be deployed, and the user should be able to override the webserver group. It seems to me like there should be an additional option for the name of the webserver's user and group, that would default to nginx, but could changed by the user to something else. Additional context Running using nixops on DigitalOcean. Metadata Please run and paste the result.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .
Because of this, running nextcloud on nixos is unnecessary difficult. There is No documentation or hint telling one has to enable the nginx server. Why is it not enabled by default? I think the module should either have working defaults or raise an error if some mandatory field is missing.
after comments earlier today about and I think you probably agree this should be enabled by default. Correct? Maybe the option doesn't even have any value at all...
Tbh I'm slightly confused that the isn't enabled by default, we should definitely alter the default to here.

AFAICS this can be fixed by using a different user/group if is disabled (currently, the group is used for pretty much everything in the Nextcloud module) this is not entirely true though, see

I tried the new nextcloud service on nixos-unstable but seems like it lacks an assert or forgets to create group for nginx since this simple config generates a deployment failure (deployed via nixops):
This could be fixed by making these configurable:
Right, this should be configurable and default to nginx if enabled, complaining if nginx is disabled and it's still set to nginx. Could one of you prepare a PR for that, possibly also editing tests, adding a variant with another webserver?
couldn't it default to another group than nginx and use nginx only if activated ? I was just trying out the module with the hope it would be straigthforward to setup so I don't think I will contribute in the short future.
it might work, but this would mean when enabling nginx, seafile's php would suddenly be executed as another user, yielding weird results due to wrong ownership of files in users data directories - I'd like to avoid that… Examples, like the VM tests, currently also enable - We could also think about enabling automatically when enabling , or make that configurable (and default to true). Do you use apache as webserver, or why don't you use ?
I've enabled nginx and deployed nextcloud on one of my machine. A quick run in journalctl shows no error (and nextcloud yet I can't access the webUI. Is there anything required to enable the webui ? I've used a fake domainName "" since my server has no domain. Could that be it ? should I address it by its IP instead ?
if nextcloud is enabled, the nextcloud module creates a with name pointing to the nextcloud installation.
That might be a bit out of scope but I tried installing nextcloud on several machines and while it seems to work locally (as in wget http://localhost), it doesn't answer to remote connections. I ran wireshark and the server returns no answer. journalctl -b0 shows my connection attempts are blocked: I looked for an nginx.firewall = enable option but that doesn't seem the case. There is a firewallfilter but I would rather enable it via a boolean than using scary iptables parameters.
about that issue, you need to open port 80/443 in the firewall, see :
That solved it thanks. I've a setting for it.

Feel free to close it but I like the coupling between the module and the firewall ports opening: Btw I am so glad I switched to nixos. The ease of installation of programs as complex as nextcloud is spectacular (and I expect the maintenance a lot easier as well). This is the kind of selfhosted program I've always wanted to do but didn't want to commit the required time because of software complexity back on ubuntu.
what's your opinion on the missing group issue in case is not enabled? While looking at roundcube, we just went with enabling nginx as soon as the roundcube module is enabled, i think this can (and should) be done here too.
no strong opinion there. Having it work by default is an improvement but what if you disable nginx (a cornercase I admit) ? you will end up with the same error.
you won't easily be able to disable nginx, as it'll be enabled by the nextcloud module automatically.
cc
what do you think about this one?
That's not right AFAICS. You can declare . So, as far as I understand, this issue is about the case where nextcloud is enabled, but nginx is disabled (and therefore phpfpm tries to use the non-existing group), right? In that case we could make nextcloud's group configurable (and set as default) and throw an eval-error if is disabled and no alternative value is declared, right? But is IMHO more experienced with phpfpm and probably has a better idea :)
We still don't have a good answer to running web applications in a more generalized fashion (ie. web server agnostic, or at least supporting multiple web servers), so I would suggest at this point if we can't fully support it we don't support it at all. If someone wants to write a (or whatever) endpoint for then we can add and support that, but as it stands there isn't much of a point to do this... is there?
The universal web service idea is tracked in , I think we should move the discussion around that into this. As nextcloud currently doesn't really work without nginx, we should probably just flip the default of to true, and update the option description to say it's currently not really possible to do it differently, so people will know they might run into problems when still disabling it. WDYT?