# Enabling CORS in nginx conf files doesn't work

**URL:** https://forum.yunohost.org/t/enabling-cors-in-nginx-conf-files-doesnt-work/28869
**Category:** Support
**Tags:** nginx, english
**Created:** [March 7, 2024, 11:31pm UTC](https://forum.yunohost.org/t/enabling-cors-in-nginx-conf-files-doesnt-work/28869 "2024-03-07T23:31:52Z")
**Posts on this page:** 10
**Page:** 1

<div class="post-metadata">

### Author: ![njiruk](https://forum.yunohost.org/letter_avatar_proxy/v4/letter/n/b5ac83/32.png) [@njiruk](https://forum.yunohost.org/u/njiruk)
#### Post date: [March 7, 2024, 11:31pm UTC](https://forum.yunohost.org/t/enabling-cors-in-nginx-conf-files-doesnt-work/28869/1 "2024-03-07T23:31:52Z")

</div>

### My YunoHost server

**Hardware:** Chuwi LarkBox Pro (Intel Celeron)  
**YunoHost version:** 11.2.9.1 (stable)  
**I have access to my server :** Through SSH & through the webadmin  
**Are you in a special context or did you perform some particular tweaking on your YunoHost instance ?** : yes  
**If yes, please explain:** not prior to handling this topic. this topic is about some tweaking…

### Description of my issue

Hi!

I’m having two use-cases listed on hold because of Cross-Origin-Resource-Sharing (CORS) issues. 1) I’m trying to use Nextcloud via webdav in an application hosted on an external website. 2) I’m trying to read in RDFa data that is stored as javascript in an HTML page on my yunohost domain from another server.  
Normally it is sufficient to make some related modifications in the relevant nginx config files (i.e. [enable cross-origin resource sharing](https://enable-cors.org/server_nginx.html)). I found those files here `/etc/nginx/conf.d/mydomain.d` but that unfortunately didn’t resolve it for me. Strangely this forum thread seems to indicate that that approach should work (for nextcloud) [Enable CORS for NextCloud](https://forum.yunohost.org/t/enable-cors-for-nextcloud/14508) - perhaps some higher-priority yunohost setting is preventing this now..?  
Also, the approach to modify these conf files would probably be a temporary fix anyway because when I edit the files it says “is meant to be read-only” below. Perhaps there could be an official yunohost-workaround instead. But I would be still happy if I have to change it after each yunohost/nginx upgrade.

For info:  
-The changes do get saved and with some other test config statements I manage to have some effects like receiving 404 errors in the client.  
-I’m reloading nginx with `/etc/init.d/nginx reload`, which seems to be the only way where I get a confirming response in the terminal.

---

<div class="post-metadata">

### Author: ![njiruk](https://forum.yunohost.org/letter_avatar_proxy/v4/letter/n/b5ac83/32.png) [@njiruk](https://forum.yunohost.org/u/njiruk)
#### Post date: [March 8, 2024, 7:43pm UTC](https://forum.yunohost.org/t/enabling-cors-in-nginx-conf-files-doesnt-work/28869/2 "2024-03-08T19:43:26Z")

</div>

Some updates, though still no break-trhough:  
-I was mistaken on the way to reload nginx. It is `systemctl restart nginx.service`. Not sure why I was getting a CLI feedback on the other command. I noticed this when I rebooted the server and nginx wouldn’t start because of an error in one of the .conf files.  
I was getting hope… I found the line that caused trouble, it was:  
`add_header 'Access-Control-Allow-Origin' '*' always;` (for the `POST` request only) - which was in the suggested code from [enable-cors.org](http://enable-cors.org) for nginx configurations. Not sure why it’s not compatible with yunohost though! I guess I’ll need that for writing into my nextcloud from an external domain, so it will probably be an issue.  
In the mean time I tested the RDFa functionality (which doesn’t require `POST` headers). But I still get a CORS error there! :~/.  
Hopefully anyone can be of help here…?

---

<div class="post-metadata">

### Author: ![tituspijean](https://forum.yunohost.org/user_avatar/forum.yunohost.org/tituspijean/32/3584_2.png) [@tituspijean](https://forum.yunohost.org/u/tituspijean)
#### Post date: [March 8, 2024, 8:58pm UTC](https://forum.yunohost.org/t/enabling-cors-in-nginx-conf-files-doesnt-work/28869/3 "2024-03-08T20:58:42Z")

</div>

> [@njiruk](#):
>
> Hopefully anyone can be of help here…?

You have put a lot of effort into not sharing any logs, verbatim errors (especially from the browser console), nor any of the modifications you made. ☹ Your use case seems quite specific, help us help you.

> [@njiruk](#):
>
> Also, the approach to modify these conf files would probably be a temporary fix anyway because when I edit the files it says “is meant to be read-only” below. Perhaps there could be an official yunohost-workaround instead. But I would be still happy if I have to change it after each yunohost/nginx upgrade.

If your use case is too specific, there always is the hooks mechanism to automate your tweaks upon each upgrade.

> [@njiruk](#):
>
> I was mistaken on the way to reload nginx. It is `systemctl restart nginx.service`. Not sure why I was getting a CLI feedback on the other command. I noticed this when I rebooted the server and nginx wouldn’t start because of an error in one of the .conf files.

The proper way is:

1. `sudo nginx -t` to test your edits
2. then `systemctl reload nginx` if the test does not fail

---

<div class="post-metadata">

### Author: ![njiruk](https://forum.yunohost.org/letter_avatar_proxy/v4/letter/n/b5ac83/32.png) [@njiruk](https://forum.yunohost.org/u/njiruk)
#### Post date: [March 8, 2024, 11:42pm UTC](https://forum.yunohost.org/t/enabling-cors-in-nginx-conf-files-doesnt-work/28869/4 "2024-03-08T23:42:32Z")

</div>

Thanks for your reply.  
I have checked on logs with `sudo yunohost log list` but that doesn’t show anything. Is there another way to get logs on yunohost’s end?  
As for the browser console. In Firefox I simply get “CORS request did not succeed” with a link to some more info [Reason: CORS request did not succeed - HTTP | MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS/Errors/CORSDidNotSucceed?utm_source=devtools&utm_medium=firefox-cors-errors&utm_campaign=default)  
In Brave (\<Chromium) I get “Access to XMLHttpRequest at ‘[https://mydomain/nextcloud/remote.php/dav/files/mypath/](https://mydomain/nextcloud/remote.php/dav/files/mypath/)’ from origin ‘[https://externalapp](https://externalapp)’ has been blocked by CORS policy: Response to preflight request doesn’t pass access control check: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.”  
Regarding modifications, I tried commenting out parts of the provided code (with or without “location”, placing it in the .conf file of the CMS app I’m using to provide the html page, and in the nextcloud.conf. I recently also tried to place it in the general nginx.conf file, and in the conf file of my domain. Nothing of all that had any influence, still receiving the same message in the browser console.  
So, my guess was that there must be some interfering higher-level nginx setting. I can’t seem to find anything, but perhaps someone here has more knowledge about nginx and the particular yunohost take on it, I was/am hoping.  
My case seems specific, but I find a couple of other threads on the forum about CORS though. An application-independent approach seems appropriate and not all that case-specific anymore. Particularly using a nextcloud via webdav in an externally hosted app is probably something quite some people would want to use.  
Thanks for the advice about hooks, that’s helpful, I was just wondering what that was meant for! And good to know about the proper use of nginx for tests!

---

<div class="post-metadata">

### Author: ![tituspijean](https://forum.yunohost.org/user_avatar/forum.yunohost.org/tituspijean/32/3584_2.png) [@tituspijean](https://forum.yunohost.org/u/tituspijean)
#### Post date: [March 9, 2024, 8:39am UTC](https://forum.yunohost.org/t/enabling-cors-in-nginx-conf-files-doesnt-work/28869/5 "2024-03-09T08:39:24Z")

</div>

I have been able to connect to my Nextcloud’s WebDAV server from an external webapp ([https://filestash.app](https://filestash.app)) without altering anything in YunoHost’s configuration.

My guess is that you have to tweak your external app’s CORS settings, not YunoHost’s, which makes sense since your browser tells you “I’m not allowed to load resources from _that other domain_”.

---

<div class="post-metadata">

### Author: ![njiruk](https://forum.yunohost.org/letter_avatar_proxy/v4/letter/n/b5ac83/32.png) [@njiruk](https://forum.yunohost.org/u/njiruk)
#### Post date: [March 10, 2024, 12:21pm UTC](https://forum.yunohost.org/t/enabling-cors-in-nginx-conf-files-doesnt-work/28869/6 "2024-03-10T12:21:07Z")

</div>

I’m positive about the CORS setting needing to happen on the yunohost server.  
The webapp you mentioned bas a certificate that expired in 2021. Perhaps yunohost has changed in the mean time.

---

<div class="post-metadata">

### Author: ![tituspijean](https://forum.yunohost.org/user_avatar/forum.yunohost.org/tituspijean/32/3584_2.png) [@tituspijean](https://forum.yunohost.org/u/tituspijean)
#### Post date: [March 12, 2024, 7:25pm UTC](https://forum.yunohost.org/t/enabling-cors-in-nginx-conf-files-doesnt-work/28869/7 "2024-03-12T19:25:48Z")

</div>

The right address is [https://www.filestash.app/](https://www.filestash.app/)

Try checking the domain.conf file too, not only the .d directory

---

<div class="post-metadata">

### Author: ![njiruk](https://forum.yunohost.org/letter_avatar_proxy/v4/letter/n/b5ac83/32.png) [@njiruk](https://forum.yunohost.org/u/njiruk)
#### Post date: [March 19, 2024, 7:48am UTC](https://forum.yunohost.org/t/enabling-cors-in-nginx-conf-files-doesnt-work/28869/8 "2024-03-19T07:48:56Z")

</div>

The filestash app ([https://demo.filestash.app/login](https://demo.filestash.app/login)) works too on my setup interestingly. Not sure why. It could be that they have implemented a proxy to deal with CORS issues.  
However, I get an error when trying with this test website [https://cors-test.codehappy.dev](https://cors-test.codehappy.dev)  
How does that work for you?

---

<div class="post-metadata">

### Author: ![njiruk](https://forum.yunohost.org/letter_avatar_proxy/v4/letter/n/b5ac83/32.png) [@njiruk](https://forum.yunohost.org/u/njiruk)
#### Post date: [March 19, 2024, 9:27am UTC](https://forum.yunohost.org/t/enabling-cors-in-nginx-conf-files-doesnt-work/28869/9 "2024-03-19T09:27:31Z")

</div>

Ahhh partial break-through…  
I already had been experimenting in the main domain config file /etc/nginx/mydomain.d/mydomain.tld.conf  
But revisiting it, I got inspired by the XMPP configuration there. It also required CORS to be allowed. I copied some of that code:

```auto
        include proxy_params;
        add_header 'Access-Control-Allow-Origin' '*';
        add_header 'Access-Control-Allow-Methods' 'HEAD, GET, PUT, OPTIONS';
        add_header 'Access-Control-Allow-Headers' 'Authorization';
        add_header 'Access-Control-Allow-Credentials' 'true';

```

to the part on the main server of my domain (the one listening on port 443).  
That at least resulted positively for most of the methods on [https://cors-test.codehappy.dev](https://cors-test.codehappy.dev)  
However, still the PUT and OPTIONS method do now work.  
I got one of my apps working, as it is only relying on data retrieval, but the nextcloud app I’m trying ([https://organice.200ok.ch/](https://organice.200ok.ch/)) is still giving CORS complaints. I’v also tried putting those CORS lines in the nexcloud.conf file. And following this advice [Add CORS Header to hosted Instance - #3 by u900x600 - 💻 Development - Nextcloud community](https://help.nextcloud.com/t/add-cors-header-to-hosted-instance/144873/3) I tried the WebAppPassword nextcloud app, which looked spot-on and promising - though no luck :~/.

---

<div class="post-metadata">

### Author: ![system](https://forum.yunohost.org/uploads/default/original/2X/f/f59fe8e3ee6b100b4f574d30d6e30479c68b89f0.png) [@system](https://forum.yunohost.org/u/system)
#### Post date: [April 18, 2024, 9:28am UTC](https://forum.yunohost.org/t/enabling-cors-in-nginx-conf-files-doesnt-work/28869/10 "2024-04-18T09:28:08Z")

</div>

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