[Solved] Cells-sync fails with ERROR http-server Request error :cannot find authority

Whew. Pydio Cells 2.X is really, really a nightmare to setup…
After hours and hours of painstakingly going through every bit of documentation I could find, I did manage to get Cells actually running and I can point my browser to it and get it to do almost everything I’ve tried so far (there seem to be still some issues with indexing folders, and I’m stumped with the Pydio 8 migration tool, but I guess that with time these problems will ‘solve by themselves’…).
Now it’s time to take a look at the brand new sync client. I was actually surprised that it was a small Go executable which launches its own web server, and it lets you add sync tasks from there… then again, why not?
Anyway… cells-sync seems to launch okay until I try to add a new task and put in the URL for my Pydio Cells 2 server. Before I even get a chance to type anything (like my username), there is a modal window that pops up, very briefly (a fraction of a second) shows the webpage for the cells-sync local webserver, and then blanks it out immediately — so fast that I barely can read anything, but after much ‘flickering’ (repeating the operation over and over again), there is some sort of ‘Disconnect’ error. I might be able to do a desktop grab and turn it into a movie and then step through it frame by frame to see if I can get a frame with the error…
On the console (I use Terminal on my Mac), as well as on the local logs, I get

2020-02-26T21:37:53.482Z        INFO     systray  Starting sub-process with args systray --url http://localhost:3636
2020-02-26T21:37:53.482Z        INFO     http-server      Starting HttpServer on localhost:3636
2020-02-26T21:37:53.482Z        INFO     scanner  Use 'quit' or Ctrl+C to exit, type 'resync', 'dry', 'loop' to control syncs, 'pause' or 'resume'
2020-02-26T21:37:53.482Z        INFO     update.service   Starting Updater Service
2020-02-26T21:37:53.804Z        INFO     systray  2020-02-26T21:37:53.804Z        INFO     systray  Opened WS Connection
2020-02-26T21:37:56.485Z        INFO     update.service   Posting Request for update
2020-02-26T21:39:38.387Z        ERROR    http-server      Request error :cannot find authority
2020-02-26T21:39:41.484Z        ERROR    http-server      Request error :cannot find authority
2020-02-26T21:51:18.700Z        ERROR    http-server      Request error :cannot find authority

… and so forth, every time I try to submit the URL for the remote Cells server.

Now, I’ve figured out that I can type http://localhost:3636 and basically do everything from there. In this case, as opposed to a ‘blank screen of death’, I get an explicit error — cannot find authority — and if I insist it will eventually just say ‘Network error’.

To give a little more information, I do have nginx as a front-end, configured using these instructions, a link that I got from reading this GitHub topic. nginx is not necessarily happy with my configuration, as shown by these logs:

2020/02/26 11:47:16 [error] 19957#19957: *4 access forbidden by rule, client: my.servers.ip.address, server: my.server.name, request: "GET /auth/dex/.well-known/openid-configuration HTTP/1.1", host: "my.server.name"
2020/02/26 11:47:16 [error] 19957#19957: *1 access forbidden by rule, client: my.servers.ip.address, server: my.server.name, request: "GET /auth/dex/.well-known/openid-configuration HTTP/1.1", host: "my.server.name"
2020/02/26 11:47:16 [error] 19957#19957: *2 access forbidden by rule, client: my.servers.ip.address, server: my.server.name, request: "GET /auth/dex/.well-known/openid-configuration HTTP/1.1", host: "my.server.name"
[...]
2020/02/26 19:20:25 [error] 9057#9057: *3766 access forbidden by rule, client: my.home.ip.address, server: my.server.name, request: "GET /oidc/.well-known/openid-configuration HTTP/2.0", host: "my.server.name", referrer: "https://my.server.name/"
2020/02/26 19:20:48 [error] 9057#9057: *3766 access forbidden by rule, client: my.home.ip.address, server: my.server.name, request: "GET /oidc/.well-known/openid-configuration HTTP/2.0", host: "my.server.name", referrer: "https://my.server.name/"
2020/02/26 19:20:52 [error] 9057#9057: *3766 access forbidden by rule, client: my.home.ip.address, server: my.server.name, request: "GET /oidc/.well-known/openid-configuration HTTP/2.0", host: "my.server.name", referrer: "https://my.server.name/"

To fix those I added the following to the nginx configuration:

    location ^~ /auth/dex/.well-known/openid-configuration {
                    proxy_buffering off;
                    proxy_pass https://my.server.name:my-port-number$request_uri;
                    proxy_set_header X-Real-IP $remote_addr;
    }

    location ^~ /oidc/.well-known/openid-configuration {
                    proxy_buffering off;
                    proxy_pass https://my.server.name:my-port-number$request_uri;
                    proxy_set_header X-Real-IP $remote_addr;
    }

This gets rid of the nginx log errors and as a bonus it even allows me to get over that ‘blank’ page — I get redirected to log in on ‘my’ Cells server, then I’m redirected back to the http://localhost:3636 page, with a box saying that I’m now authenticated and can safely close that page. I did that, went back to the Cells-Sync icon, clicked on ‘Create Task’ — and promptly got another cannot find authority error.

Whew. Back to http://localhost:3636. This time, the console logs for cells-sync are:

2020-02-26T22:10:45.790Z        INFO     oidc     Additional safe check for token https://gwynethllewelyn@my.server.name
2020-02-26T22:12:45.788Z        INFO     oidc     Additional safe check for token https://gwynethllewelyn@my.server.name
2020-02-26T22:14:45.784Z        INFO     oidc     Additional safe check for token https://gwynethllewelyn@my.server.name
2020-02-26T22:16:45.778Z        INFO     oidc     Additional safe check for token https://gwynethllewelyn@my.server.name
2020-02-26T22:17:02.746Z        INFO     http-server      Browsing https://my.server.name/ on path /
2020-02-26T22:17:03.383Z        ERROR    http-server      Request error :transport: received the unexpected content-type "text/html; charset=utf-8"

Now that’s a new one!

I promptly added proxy_set_header content-type "application/json"; to the two locations shown above, and, for good measure, added that to the location /ws as well.

However, the error persists!

(Note that during all those changes the Cells server continued to work flawlessly when connecting via the Web to https://my.server.name, logging in as usual, uploading new files, looking at older ones, adding new users, etc.)

So before I delve deep into the innards of the cells-sync code (ugh! Note that I’m not a professional programmer, just a humble Go fan & amateur programmer…), do you have any further suggestions?

Final note on my overall environment: Ubuntu 16.04.6 LTS (kernel 4.4.0-174-generic), MariaDB 10.4.12, nginx 1.14.2 (I’m sort of stuck with that — this is not the place to explain why I can’t upgrade to a newer version), and I run ISPConfig 3.1.15p3 to manage most tasks on my server (which might limit some things I can do with nginx).

Hello,
You are using self-signed certificate or another one signed by an CA?

ah… I knew I had forgotten something! Aye, I’m using a certificate from Let’s Encrypt — however, it is not being managed by Cells directly, but rather by ISPConfig, mostly because the domain my.server.name is quite old — over a decade — and has been managed that way before AjaXplorer (Pydio’s former name) was even created…

I’ve checked, and the certificate is being updated correctly.

For information, cells-sync connect to server by using gRPC protocol via http v2, So please make sure:

  • cells (ssl+httpv2) => (reverse proxy)gateway(ssl+httpv2)=> public
  • certificate signed by a CA (let’s encrypt is ok)

I’m having a very similar issue. I also have Cells running behind an nginx reverse proxy and a Let’s Encrypt certificate not managed by Cells. The Cells server works really well when connecting via web or the iOS app for me too.

The CellsSync app fails when attempting to add an account, landing me on this page my web browser can’t open:

https://localhost:3636/servers/callback?code=jSm8gQVmEqpJGspbBBVvvLU6zvFT7sh3sVDNO5_Hq5Q.YO0-J8YeOXV7Zde7Z_h8zwbyE_ALQaioteFg30T4BmM&scope=openid%20profile%20email%20pydio%20offline&state=fb48586bb8e04a559162f290e8676fb4

My console output doesn’t report any errors at all though. It prints these lines at startup and then stays quiet, even as the failed login attempts pile up:

2020-05-14T22:40:32.749+1200	INFO	Starting runner with Parent ID 24006
2020-05-14T22:40:32.750+1200	INFO	scanner	Use 'quit' or Ctrl+C to exit, type 'resync', 'dry', 'loop' to control syncs, 'pause' or 'resume'
2020-05-14T22:40:32.750+1200	INFO	update.service	Starting Updater Service
2020-05-14T22:40:32.750+1200	INFO	systray	Starting sub-process with args systray --url http://localhost:3636
2020-05-14T22:40:32.750+1200	INFO	profiler	Exposing debug profiles for process 36513 on port 6060

2020-05-14T22:40:32.750+1200	INFO	http-server	Starting HttpServer on localhost:3636
2020-05-14T22:40:33.073+1200	INFO	systray	2020-05-14T22:40:33.073+1200	INFO	systray	Opened WS Connection
2020-05-14T22:40:35.756+1200	INFO	update.service	Posting Request for update

I’ve included this bit in the nginx config and set the environment variable PYDIO_GRPC_EXTERNAL to 33060:

server {

  listen 33060 ssl http2;
  listen [::]:33060 ssl http2;

  include /config/nginx/ssl.conf;

  keepalive_timeout 600s;

  location / {
    include /config/nginx/proxy.conf;
    resolver 127.0.0.11 valid=30s;
    grpc_pass grpcs://172.18.0.5:33060;
  }
}

Any help would be appreciated :slight_smile:

Just noting that I got this to work by changing the broken URL the browser ends up at from https://... to http://.... After that, I got to the success screen and CellSync now works beautifully.

Hi @thimic
I have the same problem on Nginx for windows. Can you please help me on how to fix it? I am following instructions from
https://pydio.com/en/docs/kb/deployment/running-cells-behind-nginx-reverse-proxy

server {
listen 33060 ssl http2;
listen [::]:33060 ssl http2;
ssl_certificate c:/ssl/certificate.crt;
ssl_certificate_key c:/ssl/certificate.key;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!MD5;
keepalive_timeout 60s;

location / {
    grpc_pass grpcs://127.0.0.1:33060;
}

error_log logs/proxy-grpc-error.log;
access_log logs/proxy-grpc-access.log;
}