Note: Different causes can lead to the described error! In my case, it was a quite exotic one which probably applies to few people and cases only. However, if you’ve been through all the other “usual” fixes to no avail, this one could be worth giving a try. Funny enough, I’ve been though most other solutions and was lucky to eventually come across this one.
And, if you came here for a quick remedy and don’t have time to enjoy my fireplace stories… go ahead and skip right down to the solution. Good luck.
I’m running nextcloud on nginx mostly for photo backup of the family members’ smartphone pool. And to have a single point of sharing for some frequently used documents. Once the “brain growth pain” from adopting other people’s tutorials was accomplished, I found myself with a nice, fast, cool home cloud that I am very happy with.
Once in a while of course, there’s updates coming in for each and every of the involved components. And while nginx and the underlying Fedora server are rather no-fuzz, easy no-brainers to handle, the nextcloud updates usually leave a taste of, well, uncomfortable uncertainty on my side as to whether the whole shebang will still work as flawless as before the update.
Now, after one of the last major updates to nextcloud, I noticed that its “self-check” function kept warning me about a “missing header”:
If you’re a sparetime web admin like me, you won’t probably be able to instantly tell the right
.conf file of your nginx or the correct syntax of the line that is required to go in there so that the warning disappears. Thanks to the world wide web however, solutions to such common tasks are usually just around the corner.
The first mistake
My first mistake here was that instead of going “how-to-do-it-right” by turning to the official documentation for nextcloud on nginx and going through it, I took the lazy shortcut way: Bang some search terms into the web browser and there you go. Lo and behold – I quickly found useful advice, mostly inside threads of the nextcloud forums.
Quick and dirty: Hasty loading the respective
.conf file in a text editor and carelessly copy-paste someone’s line in it.
Save. Quit. Restart nginx. Browse that security check page.
But it didn’t work. Crap.
I double-checked what I did, what others wrote, re-rewrote the stuff into the file, and restarted basically everything from nginx to the entire machine… to no avail.
That warning was still there.
The second mistake
My next step was to figure out if that warning was indeed correct. You never know what someone’s code is looking for and maybe they’re just doing it wrong. Perhaps they only tell that the header is missing – while instead it actually is present? Maybe, maybe, despite a proven track record of great complex code that is providing a gorgeous solution …they simply fail at simple things? Okay – time to trust no one again and launch developer tools in my browser to have a look at… Damn, it’s there!
Ha! You see – I was right: They’re morons and I’m a genius!
Fine, fine… okay, but… how to fix it?
I cannot be the only one under god’s sun to have this problem. There’s always someone else. Hopefully that someone came up with a solution. Okay, time to concentrate, take it serious, take a deep breath and dive into forums and read threads entirely and carefully. Hopefully I wouldn’t have to go the full monty… way down to stackoverflow.
It turned out, that there was some “mess” happening across recent versions of nextcloud regarding that header. At some point, according to someone, it appeared to have been “provided by PHP” instead of nextcloud’s config files – whatever that means (probably referring to nextcloud’s PHP code). Other people said it was moved from one config file to another, finally not being present at all and eventually requiring people to have to add it manually to their configs. Or so. Plus, rumor has it that, if it appeared more than once inside the nginx config “stack”, it could probably also result in having no effect at all despite being there. The exact situation and history was basically undeterminable due to contradictive posts and opinions spread across forum threads.
The bottom line up to that point is:
People had it in their config but it somehow wasn’t working. I knew how that felt. Each “Works for me” claim in the forum yielded three times as much claims “I’ve copied your VERY line EXACTLY to my config and it DOES NOT work”.
Here’s some of the history and controversy:
The #facepalm solution
Then finally, after reading another thread up until its veeery end, I stumbled across a single comment. The eye-catching, jaw-dropping,
#headdesk moment of clarity:
Wait, what? Holy crap – seriously?
Yup. And that’s exactly what happened in my case as well!
I fired up the terminal, opened the respective
nginx config file in
nano, and replaced these pasted typographic double quotes with plaintext double quotes. Saved, closed, restarted
nginx, browsed to its admin overview page and impatiently waited for the self-check to finish…
VarIr – you saved the day! Perhaps not just for me but certainly for a whole lot of people. Thanks for sharing!
The bottom line: Be aware of copy-pasting stuff from a web browser window into a code editor, even if taken from text blocks that appear to use
I’m not blaming the nextcloud floks, nor the makers of the CSS or forum, nor the folks posting their comments. The only one to blame is me: I should have noticed that right after pasting the line in my text editor. I’m using a suitable coding font that reveals these discrepancies, even if they’re hard to see at first sight.
Lessons I’ve learned (again)
Regarding my first mistake: I should have re-typed the line from the official “sample config” which someone took the pain to carefully provide for nginx admins. Or at least, copy-paste if from there.
Regarding my second mistake: Instead of trusting only the developer-tools of Chromium, I should have cross-checked with one or more other tools. For example, this is how to check the headers using
curl – and ignore SSL errors:
curl -I -k https://yournextcloudURL/login
By doing so, you’d get a list of headers and their values. The wrongly-enclosed
SAMEORIGIN header looks like this in a terminal output of
You think that’s the holy grail of seeing clear? You ain’t seen nothin’ yet! Here’s Firefox’s developer tools on that header:
The good thing about this is that I was able to spot a similar issue in a Groovy test script of a colleague only a fews days later. They
also double-checked everything but couldn’t explain where their syntax error was coming from.
I was painfully aware of it by then. You live and you learn.
Copyright notice for artwork used on this page (in addition to these):