How to exclude .well-known folder when upgrade?

ℹ️ Support
,
1

Hi all,

I’m recently updatef from 10.0.1 to 10.0.2 by used the auto updater.
It’s working fine except one issue.

In order for me to proceed the update, I had to removed the .well-known/acme-challenge folders.
The problem is that this folder use for Let’s Encrypt (SSL).
Meaning I had to deleted the folder prior to update, and copy the folder .well-known/ back to the new installation folder.
This is a hassle.

Any work-around solution?

Thanks.

2

You already presented a work-around.

@LukasReschke, there are plans to ignore the asset folder, should this request be added to this issue or rather a new one?

4

We won’t exclude the .well-known folder. If one uses LetsEncrypt that should be handled on the VirtualHost layer.

5

I know, but the folder has to be in the Nextcloud webroot in order for Let’s Encrypt verification to work.
Why you guys can’t exclude .well-known folder?

1 Like
6

You can do this, for nginx for example:

7

Thanks, I’ll look into it.

8

Hi,

What’s the different between ?:

   location ~ ^/.well-known/acme-challenge/* {
    allow all;
}


location ^~ /.well-known/acme-challenge/ {
  alias /var/www/acme-challenge/;
}



   location ~ ^/.well-known/acme-challenge/ {
    allow all;
}
9

I’m no expert to nginx syntax, the first and last example seem to be the same and grant access to everybody. The second just sets an alias for .well-known/acme-challenge/ so the content is not in your main document-root (and it won’t trigger the code-checker).

10

Adding to what @tflidd correctly explained I would avoid the syntax of the first and third location lines, because locations preceded by a ~ are regular expressions. And in regular expressions / need to be escaped.

Assuming that /* is meant to be \/.* and not \/* (which in my opinion doesn’t make any sense) the first and third location lines should be:
location ~ ^\/\.well-known\/acme-challenge\/.* {
and
location ~ ^\/\.well-known\/acme-challenge\/ {
Those two lines would actually match the same requests.

The ^~ before the second location block means, that the location is not a regular expression, but a prefix string with a special meaning: if a request matches this prefix string, location blocks with regular expressions won’t be tested.

So if all three lines would reside in the same nginx server block, requests starting with /.well-known/acme-challenge/ would all be served by the second location block (regardless of the order of the three location blocks!). Here is what the nginx docu says about location blocks: https://nginx.org/en/docs/http/ngx_http_core_module.html#location

There is also a very good article at digitalocean about location blocks in nginx:

Hope that helps! Cheers, Bernie_O

1 Like
11

I’ve figured for sometimes now.
I’m using this location ^~ /.well-known/acme-challenge/ { allow all; }
And it’s working fine.

Thanks guys.

12

well the problem is that at least on my hoster that they always put the well known folder there, and honestly I dont see a reason why it should be a problem to exclude those.

13

I have to agree. I just did an upgrade to 13rc1 and bumped into this issue. Sure I can temporarily move the folder up one level out of the way but my entire LetsEncrypt strategy (including weekly updates which will auto recreate that .well-known directory) is based on that canonical folder being in the root of the domains web area. My Thunderbird auto-configuration strategy also relies on that directory being there and I can’t predict when someone will want to add a new mail account to manually move the directory in or out of the root webarea just to suite a possible Nextcloud update. Setting up an alias with nginx is very fragile when rolled out to 100s of vhost sites compared to perhaps a one line change in the Nextcloud source to ignore what is indeed a Well Known folder called .well-known for a very good reason.

14

seriously, this is discussed for over two years now? what a no-brainer…

2 Likes
15

Have to agree, a no-brainer. Given how many folk report this and suffer from it and how, er, well known the .well-known, folder is, surely it’s a piece of pie for an updater to quietly ignore it … maybe reporting that it’s done so but sheesh, if you’re gonna bomb at least print the full path to the danged file (took me some thinking and poking round to work out where it was as I have a few ;-). Seems to me to cover the basic criteria for a no-brainer … lots of people inconvenienced with a less than slick experience, confronting confusion and uncertainty when a simple acknowledgement that this well known folder is expected and not an issue.

16

actually there has been work on it (it is an rfc so not really something NC can run from) and considering a fix was merged in november I would guess it isnt a problem for future updates anymore.


1 Like
17

Looks like you’re right! I just tried the 15.06 to 15.08 update anyhow and it worked. it didn’t barf about .well-known!