Launching Drive from tray app... Wrong URL?

[Telos]

What have I done now? When I click (Synology Drive) from the Windows Drive tray app. it tries to launch...

https://secretword.synology.me/drive/?launchApp=SYNO.SDS.Drive.Application

But this goes nowhere without the forwarded https port number.

In Application Portal I have only alias "drive" selected. Out of curiosity, I changed that to "dr" and still the launch link showed "drive" (and no port), so that went nowhere.

I'm reasonably certain I used to be able to open the Drive login screen using the tray app... Same problem with 3 browsers. If I add the port manually, it works. If I try to use the port in Application Portal it tells me that port is already in use (yeah... it's my https port)

My head is spinning. What am I doing wrong?

FWIW, my Windows app is using my QuickConnect ID to login (which apparently directs to my DDNS). Seems like QuickConnect should use my LAN IP when I'm on the LAN (which I am for this mess).

 

[Rusty]

Can you share your app portal config for the Drive? Personally I use it with a subdomain name and its working just fine (custom domain option). Running Drive as an alias (subdir) shouldn't ask for a port if your root access is https (if your root access also works with no port).

 

[fredbert]

If I try using the QuickConnect relay from the home LAN then it does change to the NAS's local IP and add the port number.

If I use the right form of this (using my Drive alias and synology.me DDNS) then it also works by resolving on the Internet and looping back in.
https://secretword.synology.me/drive/?launchApp=SYNO.SDS.Drive.Application

Have you tried using a vanilla Windows account to see if you have a setting or app interfering?

 

[Telos]

Can you share your app portal config for the Drive?

It's pretty spartan...

 

[Telos]

it also works by resolving on the Internet and looping back in.
https://secretword.synology.me/drive/?launchApp=SYNO.SDS.Drive.Application

FWIW... I cannot reach DSM with
https://secretword.synology.me

I must use the port
https://secretword.synology.me <-- I'm not sure how I did that,,, "forum magic".

https://secretword.synology.me:1234

Maybe that is the problem

 

[fredbert]

Odd. A potential kludge would be to try to add a reverse proxy for secretword.synology.me port 443 to localhost port 1234.

I have a similar thing for a second DSM NAS.

 

[Telos]

A potential kludge would be to try to add a reverse proxy for secretword.synology.me port 443 to localhost port 1234.

Maybe I'm doing this wrong... but when I use "secretword.synology.me" as the source hostname it fails... "The domain name is already in use".

 

[fredbert]

Ok, I wondered if that would happen, hence 'try to add'. There's already a configuration for this combination of values.

You could remove the PC from the equation: try from another client device of even SSH and curl from the NAS.

I recall in a response to someone you said you didn't have CP / External Access / Advanced set for external ports. I do and they are set the same as I have changed the DSM ports for HTTP/HTTPS.

My CP / QuickConnect / Advanced settings are all enabled except automatically creat port forwarding rules.

 

[Rusty]

A potential kludge would be to try to add a reverse proxy for secretword.synology.me port 443 to localhost port 1234

I was about to offer this as well. Just target NAS towards its http/5000 (default) port, no need to push https to https via revers.

 

[Telos]

You could remove the PC from the equation: try from another client device of even SSH and curl from the NAS.

I tried a second PC. Same issue... browser URL launched from its Windows Drive app is
https://secretword.synology.me/drive/?launchApp=SYNO.SDS.Drive.Application

Interestingly... I changed the alias in Application Portal to "dr"... but this does not affect Windows' Drive app. It still uses "drive" <-- maybe that is a hard-coded alias?

I recall in a response to someone you said you didn't have CP / External Access / Advanced set for external ports. I do and they are set the same as I have changed the DSM ports for HTTP/HTTPS.

I changed those to 1230 (http) and 1234 (https) with no effect. The Windows Drive app uses my DDNS without port 1234. Out of curiosity, I changed the Windows Drive app connection to use my local LAN 192.168.1.10, and still, it launches my DDNS URL without the port.

My CP / QuickConnect / Advanced settings are all enabled except automatically creat port forwarding rules.

Same here.

 

[Telos]

I was about to offer this as well. Just target NAS towards its http/5000 (default) port, no need to push https to https via revers.

Assuming ports 1230 (http) and 1234 (https) and forwarding via router 1234 (WAN) > 1234 (LAN/NAS IP), I'm not sure I follow... Reverse Proxy seems to balk when I try...

I don't believe I'm understanding what you are suggesting, as 443 doesn't work here.

 

[fredbert]

Hostname = '*' needs to change to 'secretname.synology.me'

The Drive app will be whatever you entered the URL and it tested when you setup the connection. With the alias there's no need to add ?launchApp=...

 

[Telos]

If I set the reverse proxy like that, then I will need to forward 443 (WAN) to 443 (LAN) at my router
... if I'm doing that I could just as well forward 443 to 1234 (my custom port) and no reverse proxy is required.

Yes/No? Security issues?

This used to work just fine, and I never forwarded 443. Confused.

 

[jeyare]

@Telos
There is a simple solution for the desktop client app “custom” port

As was written here few times - use setup in Drive admin console - Custom port

 

[Telos]

use setup in Drive admin console - Custom port

Was that ever buried...

This is working.

 

[fredbert]

This used to work just fine, and I never forwarded 443. Confused.

I'm not sure. If it used to work and nothing has changed then I'm stumped for now.

Update (1 minute later)...
OK if that's working with the custom sharing link. But I thought that that base URL was for when sharing a file/etc within Drive. Is that then also used for directly accessing by the client app?

My customised domain is set as my Drive subdomain of my personal DDNS domain using HTTPS, no port.

 

[Telos]

I thought that that base URL was for when sharing a file/etc within Drive. Is that then also used for directly accessing by the client app?

Apparently it is, because when I changed it to "QuickConnect" (versus "Custom") the Windows Drive app launched a QuickConnect URL; when I selected DDNS, the Windows Drive app launched the DDNS URL (with no port). So I used "Custom", added the DDNS port, and it launched the DDNS URL w/port, and of course that connected.

So... this affects more than "sharing" (which is now back with "DDNS: port")... for better or worse.

 

[Telos]

Letting the dust settle... I discovered that unchecking "Enable sharing Link customization" was at the heart of my issue. Now when Drive is launched from the tray app, it launches with the port number.

It seems that "Enable sharing Link customization" (Synology Drive Admin Console) overrides Drive's Application Portal settings unless you choose "Synology Drive customized domain" from the "Enable sharing Link customization" dropdown box.

All in all this my problem grew out of the recent thread involving sharing Synology Office files. I didn't realize tweaking the share link would also affect the Drive tray app. After reading the Knowledge Base article on How to set up connection to Synology Drive server I can see what an entangled mess Drive is.

Thanks to all here.

 

[jeyare]

@Telos
thx for a better feeling for this day. I like read a stories with good end
Just knowledge improvement can bring better usage of all the tools what can help us do [almost everything] better.
Uff, morning cup of coffee and such Philosopher’s stone thought

 

[fredbert]

I'm guessing that by setting customised sharing link that Drive infers that you know what you're doing and that QuickConnect relay assumes this customised link will work for Drive itself too.

I'm still not sure why you need to add DSM HTTPS port when using the Drive alias because the aliases normally are a HTTPS 443 internal redirect.

It's really not obvious why this is happening or is it too early for me and not enough yet to start the synapses sparking?