Share link issues

Question

Share link issues

Ju1-js opened this issue 2 years ago · 43 comments

Describe the bug

There was an issue for this before, but even the test code that worked for them doesn't work for me.
The code works for me on Gradio 1.18.0, but the moment I upgrade past it ex. 1.19.x+. The share link breaks.

Is there an existing issue for this?

I have searched the existing issues

Reproduction

import gradio as gr

def greet(name):
    return "Hello " + name + "!"

demo = gr.Interface(fn=greet, inputs="text", outputs="text")
    
demo.launch(share=True, debug=True)

Logs

py --version
Python 3.11.1

py -m pip list
Package            Version
------------------ ---------
...
gradio             3.23.0
...

System Info

Gradio version: 3.23.0
Os: Windows 10 21H2 (OS Build 19044.2604)
Browser: Brave - Chromium

Severity

Blocking upgrade to latest gradio version

Answer 1 · 2023-03-29T07:48:21.000Z

I have the same problem with VSCode.
I tried yesterday a couple of times and the same today.

I have the latest version of vscode (1.76.2) and from Gradio (3.23.0)
Python (3.10.7)

Answer 2 · 2023-03-29T13:38:51.000Z

Taking a look! @Chris-pap what OS are you running?

Answer 3 · 2023-03-29T13:39:27.000Z

I'm also going to pin this issue. If anyone else is experiencing share link issues, please chime into this issue

Answer 4 · 2023-03-29T13:42:00.000Z

Taking a look! @Chris-pap what OS are you running?

Windows 11 Home , 22H2, 22621.1413

Answer 5 · 2023-03-29T13:47:12.000Z

Do you guys have an antivirus that's running? It looks like Windows Defender sometimes blocks the share link binary file from running. See #3230

Answer 6 · 2023-03-29T14:50:23.000Z

Do you guys have an antivirus that's running? It looks like Windows Defender sometimes blocks the share link binary file from running. See #3230

I have windows defender and Malwarebytes, i deactivate both of them but it didn't fix the problem.

Answer 7 · 2023-03-30T16:04:42.000Z

That was the issue for me! Thanks!
@Chris-pap Check protection history, it may have already been quarantined so that when defender or Malwarebytes was deactivated, it wouldn't change anything.

Answer 8 · 2023-03-30T16:21:31.000Z

@Chris-pap Check protection history, it may have already been quarantined so that when defender or Malwarebytes was deactivated, it wouldn't change anything.

I am keep having the same problem. (blocked apps are not from gradio)

Answer 9 · 2023-03-30T17:25:27.000Z

Thanks @Ju1-js for letting us know. @Chris-pap, sorry this didn't solve it for you, I'll let you know if we can think of anything else that may be going on.

Answer 10 · 2023-04-01T06:31:23.000Z

Ok I've found solution for my problem on this link as Abidlabs shared
https://www.makeuseof.com/how-to-whitelist-files-windows-defender/

I've whitelisted entire Folder instead of just the app.py which worked for me

Answer 11 · 2023-04-11T20:05:34.000Z

Most problems seem resolved.

Answer 12 · 2023-06-20T13:00:27.000Z

@Chris-pap Check protection history, it may have already been quarantined so that when defender or Malwarebytes was deactivated, it wouldn't change anything.

I am keep having the same problem. (blocked apps are not from gradio)

maybe you run the code in a server with the proxy? I closed the agents and the problem is solved.

Answer 13 · 2023-06-29T08:33:24.000Z

I met the same problem on Ubuntu, any solution?

Answer 14 · 2023-07-25T11:43:31.000Z

I also encountered this issue in a remote notebook that is different from colab, kaggle, sagemaker etc.

share = True outputs only Running on local URL: http://127.0.0.1:7860/, the share link is not created, and the kernel keeps busy.

More details see: #2918 (comment)

Answer 15 · 2023-08-13T12:36:34.000Z

I met the same problem on Ubuntu, any solution?

I met the same problem on ubuntu2204,have you solved this problem?

Answer 16 · 2023-09-08T13:25:09.000Z

With sd I edited the bat file added --share --gradio-auth someUsername:somePassword and it works just fine

Answer 17 · 2023-09-25T20:16:51.000Z

@abidlabs It seems that the tunneling.py code is not written to cover any error that happens with the underlaying binary. The while loop never exits and sometimes even misses errors. For example on my system (Windows 11), the line printed by frpc reads:

2023/09/25 22:10:51 [W] [service.go:132] login to server failed: dial tcp 44.237.78.176:7000: i/o timeout

And now gradio will just wait forever for a line that reads start proxy success: (.+)\n. But all the lines that are sent by frpc are just \n and not None.

while url == "":
    if self.proc.stdout is None:
        continue
    line = self.proc.stdout.readline()
    line = line.decode("utf-8")
    if "start proxy success" in line:
        result = re.search("start proxy success: (.+)\n", line)
        if result is None:
            raise ValueError("Could not create share URL")
        else:
            url = result.group(1)
return url

In my opinion this code should have a limit of messages to check before exiting gracefully and raising a proper exception with all the lines logged to the error stream.

Answer 18 · 2023-09-25T20:19:16.000Z

Thanks @cansik I believe you are correct. Would you like to open a PR in which any errors are outputted to the user?

Answer 19 · 2023-09-26T01:25:18.000Z

@abidlabs It seems that the tunneling.py code is not written to cover any error that happens with the underlaying binary. The while loop never exits and sometimes even misses errors. For example on my system (Windows 11), the line printed by frpc reads:
2023/09/25 22:10:51 [W] [service.go:132] login to server failed: dial tcp 44.237.78.176:7000: i/o timeout
And now gradio will just wait forever for a line that reads start proxy success: (.+)\n. But all the lines that are sent by frpc are just \n and not None.
while url == "":
    if self.proc.stdout is None:
        continue
    line = self.proc.stdout.readline()
    line = line.decode("utf-8")
    if "start proxy success" in line:
        result = re.search("start proxy success: (.+)\n", line)
        if result is None:
            raise ValueError("Could not create share URL")
        else:
            url = result.group(1)
return url
In my opinion this code should have a limit of messages to check before exiting gracefully and raising a proper exception with all the lines logged to the error stream.

I also found out that this was a problem while debugging. The while loop never exits.
I used to get a public ip and share the link as a temporary measure like this.


#while url == "":
        #    if self.proc.stdout is None:
        #        continue
        #    line = self.proc.stdout.readline()
        #    line = line.decode("utf-8")
        #    if "start proxy success" in line:
        #        result = re.search("start proxy success: (.+)\n", line)
        #        if result is None:
        #            raise ValueError("Could not create share URL")
        #        else:
        #            url = result.group(1)
public_ip = subprocess.run(["curl", "ifconfig.me"], stdout=subprocess.PIPE)
url = f"http://{public_ip.stdout.decode('utf-8')}:{self.local_port}/"
return url

Answer 20 · 2023-09-28T09:25:07.000Z

@abidlabs Have a look at #5731

Answer 21 · 2023-10-03T02:57:55.000Z

So I was using SD.Next when my URL was... cancelled? Reset? Anyhow, the only thing I can think of other than a bug is that my VPN reset the IP address for my home PC, causing the url to be reset or something. Since --share with any Automatic1111 fork is inherently insecure (anyone with access to the URL could potentially use it for nefarious purposes I assume), I'd ideally always be using a VPN like ExpressVPN when opening my instance to the web.

Please let me know if you need any more info from me, I'll do my best.

Answer 22 · 2023-10-03T03:02:26.000Z

So I was using SD.Next when my URL was... cancelled? Reset? Anyhow, the only thing I can think of other than a bug is that my VPN reset the IP address for my home PC, causing the url to be reset or something

That is indeed quite possible, if your connection dropped / reset, the share link could be broken. Has this happenened repeatedly, or only once?

Answer 23 · 2023-10-03T03:08:35.000Z

It happened twice in one day, about two hours apart. When I got home from work and was able to view the console, I didn't see any specific errors or anything there, which makes me think it's more on the Gradio-side of things. It's a totally understandable function, I'm wondering if there is something that could be done by SD.Next to perhaps try to re-connect, or maybe a bit of lag time after the connection drops before the url gets reset? I'm so out of my depth here lol. Thanks for your help.

Answer 24 · 2023-10-27T19:59:09.000Z

To anyone following along this issue, we are planning on open-sourcing our FRP server as part of the launch of Gradio 4.0. You can see this PR: #6091, or join us for the launch of 4.0, where we'll discuss this in more depth.

Answer 25 · 2023-12-26T18:58:10.000Z

From (closed) #6880 :

Gradio Environment Information:

Operating System: Windows
gradio version: 4.12.0
gradio_client version: 0.8.0

gradio dependencies in your environment:

aiofiles: 23.2.1
altair: 5.2.0
fastapi: 0.105.0
ffmpy: 0.3.1
gradio-client==0.8.0 is not installed.
httpx: 0.26.0
huggingface-hub: 0.19.4
importlib-resources: 6.1.1
jinja2: 3.1.2
markupsafe: 2.1.3
matplotlib: 3.8.2
numpy: 1.26.2
orjson: 3.9.10
packaging: 23.2
pandas: 2.1.4
pillow: 10.1.0
pydantic: 2.5.2
pydub: 0.25.1
python-multipart: 0.0.6
pyyaml: 6.0.1
semantic-version: 2.10.0
tomlkit==0.12.0 is not installed.
typer: 0.9.0
typing-extensions: 4.8.0
uvicorn: 0.25.0
authlib; extra == 'oauth' is not installed.
itsdangerous; extra == 'oauth' is not installed.

gradio_client dependencies in your environment:

fsspec: 2023.12.1
httpx: 0.26.0
huggingface-hub: 0.19.4
packaging: 23.2
typing-extensions: 4.8.0
websockets: 11.0.3

Answer 26 · 2024-01-10T11:33:28.000Z

我在Ubuntu上也遇到了同样的问题，有解决办法吗？

I want to know how you solved it

Answer 27 · 2024-02-15T17:30:31.000Z

@abidlabs I changed mine NVAPI Key and nothing changed =/
What I should do than?

Answer 28 · 2024-04-11T20:21:21.000Z

I have the same issue actually.
I am trying to generate a shareble link with gradio, but I am getting the following error message:

2024-04-10 16:46:50 | ERROR | stderr | 2024/04/10 16:46:50 [W] [service.go:132] login to server failed: dial tcp 44.237.78.176:7000: i/o timeout
2024-04-10 16:46:50 | INFO | stdout | 
2024-04-10 16:46:50 | INFO | stdout | Could not create share link. Please check your internet connection or our status page: https://status.gradio.app.

I have:

gradio                    4.16.0                   pypi_0    pypi
gradio-client             0.8.1                    pypi_0    pypi

I have seen it is possible to deal with it downgrading gradio to 3.9, but currenlty I have a strict requirement using this version.

Reproduction

import gradio as gr

def greet(name):
    return "Hello " + name + "!"

demo = gr.Interface(fn=greet, inputs="textbox", outputs="textbox")
    
demo.launch(share=True)  # Share your demo with just 1 extra parameter 🚀

Logs

2024-04-10 16:46:34 | INFO | httpx | HTTP Request: GET https://api.gradio.app/pkg-version "HTTP/1.1 200 OK"
2024-04-10 16:46:35 | INFO | httpx | HTTP Request: POST https://api.gradio.app/gradio-initiated-analytics/ "HTTP/1.1 200 OK"
2024-04-10 16:46:37 | INFO | stdout | Running on local URL:  http://0.0.0.0:7860
2024-04-10 16:46:37 | INFO | httpx | HTTP Request: GET http://localhost:7860/startup-events "HTTP/1.1 200 OK"
2024-04-10 16:46:37 | INFO | httpx | HTTP Request: HEAD http://localhost:7860/ "HTTP/1.1 200 OK"
2024-04-10 16:46:40 | INFO | httpx | HTTP Request: GET https://api.gradio.app/v2/tunnel-request "HTTP/1.1 200 OK"
2024-04-10 16:46:50 | ERROR | stderr | 2024/04/10 16:46:50 [W] [service.go:132] login to server failed: dial tcp 44.237.78.176:7000: i/o timeout
2024-04-10 16:46:50 | INFO | stdout | 
2024-04-10 16:46:50 | INFO | stdout | Could not create share link. Please check your internet connection or our status page: https://status.gradio.app.
2024-04-10 16:46:51 | INFO | httpx | HTTP Request: POST https://api.gradio.app/gradio-launched-telemetry/ "HTTP/1.1 200 OK"
2024-04-10 16:46:51 | INFO | httpx | HTTP Request: POST https://api.gradio.app/gradio-error-analytics/ "HTTP/1.1 200 OK"

System Info

gradio                    4.16.0                   pypi_0    pypi
gradio-client             0.8.1                    pypi_0    pypi

Answer 29 · 2024-04-12T17:20:43.000Z

+1 Same issue as above

Answer 30 · 2024-05-16T17:35:56.000Z

still not works, no public link appears

Answer 31 · 2024-05-24T08:59:55.000Z

I encounter this issue today. I'm using gradio v3.41.2 and gradio-client v0.5.0. After starting a demo.launch(share=True), the console output only gives local url, but no share links. When I hit ctrl-c, the trackback shows:

File "${HOME_PATH}/min_test.py", line 8, in <module>
    demo.launch(share=True)
  File "${CONDA_PATH}/lib/python3.9/site-packages/gradio/blocks.py", line 1995, in launch
    self.share_url = networking.setup_tunnel(
  File "${CONDA_PATH}/lib/python3.9/site-packages/gradio/networking.py", line 190, in setup_tunnel
    address = tunnel.start_tunnel()
  File "${CONDA_PATH}/lib/python3.9/site-packages/gradio/tunneling.py", line 60, in start_tunnel
    self.url = self._start_tunnel(BINARY_PATH)
  File "${CONDA_PATH}/lib/python3.9/site-packages/gradio/tunneling.py", line 97, in _start_tunnel
    line = self.proc.stdout.readline()

After some digging, I find that the problem comes from frpc. In tunneling.py's _start_tunnel function, gradio starts a subprocess to run this command and wait for response:

${CONDA_PATH}/lib/python3.9/site-packages/gradio/frpc_linux_amd64_v0.2 http -n ${SHARE_TOKEN} -l 7860 -i 127.0.0.1 --uc --sd random --ue --server_addr 44.237.78.176:7000 --disable_log_color

However, when I try to execute the command directly in the shell, I get login to server failed: dial tcp 44.237.78.176:7000: i/o timeout. Moreover, the ip 44.237.78.176 cannot be reached through ping.
Also, I tried to find out where does this IP address come from, and I found it in networking.py's setup_tunnel function, which request https://api.gradio.app/v2/tunnel-request and gets a dict.
I also tried to directly access the https://api.gradio.app/v2/tunnel-request through browser, and I got a JSON [{"host": "44.237.78.176", "port": 7000}].
I think this is the reason of this weird problem. Maybe the share link server's IP address has been updated, but the tunnel-request API is still returning old IP address? I wonder the reason.

Answer 32 · 2024-05-24T20:03:47.000Z

Will look into this but just fyi 44.237.78.176 is the correct IP address for the FRP server

Answer 33 · 2024-05-26T15:33:53.000Z

Will look into this but just fyi 44.237.78.176 is the correct IP address for the FRP server

Thank you ! I'm also wondering, are there any other ways to share my gradio app than requesting a shared link with frpc? For example, using IP and port? As far as I know, the local url is not available for remote access now.

Answer 34 · 2024-05-27T04:33:19.000Z

Thank you ! I'm also wondering, are there any other ways to share my gradio app than requesting a shared link with frpc? For example, using IP and port? As far as I know, the local url is not available for remote access now.

SSH port forwarding is always an option: https://www.ssh.com/academy/ssh/tunneling-example

Answer 35 · 2024-05-27T06:27:54.000Z

Thank you ! I'm also wondering, are there any other ways to share my gradio app than requesting a shared link with frpc? For example, using IP and port? As far as I know, the local url is not available for remote access now.

SSH port forwarding is always an option: https://www.ssh.com/academy/ssh/tunneling-example

OK, thanks! Forgot this😂

Answer 36 · 2024-05-31T06:30:32.000Z

So has this problem been solved? I am also facing the same problem now

Answer 37 · 2024-06-01T02:39:32.000Z

So has this problem been solved? I am also facing the same problem now

Which problem exactly?

Answer 38 · 2024-06-06T03:55:22.000Z

In practice, the following method can be used to solve this problem：
chmod +x /path/frpc_linux_amd64_v0.2

Answer 39 · 2024-06-28T14:36:40.000Z

Hi folks, just a heads up that we have discovered a security vulnerability with how share links were created in gradio<=3.13, and will be disabling share links for this version starting next Wednesday. Please upgrade to a more recent version of gradio, and if you are having issues creating share links in more recent versions, please respond in this issue so that we can help fix it.

Answer 40 · 2024-10-11T08:21:46.000Z

Sharing links works on my machines with pre-5.0.1 builds - but sadly broke after moving to 5! Unfortunately, the logs don't have much information to share as the more information is followed by an empty log.

Could not create share URL. Please check the appended log from frpc for more information:

It seems like the new binary is getting killed on my machine? Looks like the binary got re-vamped and pushed to a new version, but not sure what the cause could be. Confirmed that sharing works as expected if I revert to a 4.x version.

OS Info

LSB Version:    core-11.1.0ubuntu4-noarch:security-11.1.0ubuntu4-noarch
Distributor ID: Ubuntu
Description:    Ubuntu 22.04 LTS
Release:        22.04
Codename:       jammy

Answer 41 · 2024-10-19T06:13:11.000Z

I still cannot use gradio to create a shared link on Win 11 23H2. The gradio version is 5.1.0. The error is as follows.

Could not create share link. Please check your internet connection or our status page: https://status.gradio.app/.
2024/10/19 14:05:29 [W] [service.go:132] login to server failed: dial tcp 44.237.78.176:7000: i/o timeout

Answer 42 · 2024-11-04T05:54:01.000Z

Has the problem been sovled? I encounter it in my docker container with VS Code
Could not create share link. Please check your internet connection or our status page: https://status.gradio.app/. 2024/11/04 05:49:29 [W] [service.go:132] login to server failed: dial tcp 44.237.78.176:7000: i/o timeout

Answer 43 · 2024-11-11T23:35:04.000Z

+1 Same issue as mentioned

OS: Win 10
env: conda environment
Gradio version:
gradio 5.5.0 pypi_0 pypi