Launch Rstudio-Server docker in port 8888

I have created a Rserver docker image from a templated based on GitHub - rocker-org/rocker-versioned2. The image works perfectly in my local machine, the only difference is that I would like to use the 8888 port rather than 8787. Therefore, I modified the ENTRYPOINT to:

usr/lib/rstudio-server/bin/rserver --www-port=8888 --auth-none=1 --server-daemonize=0

You can see the full docker file here. The problem ist that when I use any port that is not the 8787, I cannot launch the session on the browser. I see The page isn’t redirecting properly or The connection was reset. However, I can see that Rserver is running:

$ ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 18:37 pts/0    00:00:00 bash /usr/run_simple.sh
rstudio+    19     1  0 18:37 pts/0    00:00:00 /usr/lib/rstudio-server/bin/rserver --www-port=8888 --auth-none=1 --server-daemonize=0
root        70     0  0 18:37 pts/1    00:00:00 bash
root        87    70  0 18:46 pts/1    00:00:00 ps -ef

Therefore, I was wondering if anyone knows how to properly launch the Rserver so that I can open it with 0.0.0.0:8888 or http://localhost:8888/.

Thanks for your feedback.

Great question! And welcome to the community!

I would check inside the container with apt install net-tools and netstat -lntp to confirm RStudio is listening where you expect. Then I would test it with curl: curl -i http://localhost:8888 from inside the container

Further, I'd love to see how you are launching the container. Something like this will be important to ensure ports are mapped properly to your host

docker run -it -p 8888:8888 containername

Once that is accomplished, I would open up your browser devtools (network tab) and see what is going on. It's probably also worth discarding any cookies / using an incognito browser / etc. to ensure there is not some browser state involved!

Hi Cole,

I am building the image with the VScode extension, so I use the "click interface". This is how the command translates: docker run --rm -it -p 8787:8787/tcp -p 8888:8888/tcp gradientrstudio:local . So I guess I am already doing what you suggest?

Awesome! Yeah, I'm not completely sure that I follow what you mean by the VSCode extension.

In any case, the netstat -lntp piece will still be useful to see whether the service is alive / listening and where it is listening.

It is useful to isolate an issue. You know that access from outside the container on port 8888 is failing. We want to move closer to the process by moving into the container, looking at the processes running (ps -ef) and processes listening on which ports (netstat -lntp), etc.

Hi Cole,

Sorry for my sloppy response. What I mean by "I use the VScode extension" is that I am building the docker image with VScode using the Docker extension. Thus, to build the image I generally do rigth-click on the dockerfile and select build, which translates in the command that I previously posted.

Regarding your suggestionnetstat -lntp, this is what I see when I run it from inside the container:

$netstat -lntp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:8888            0.0.0.0:*               LISTEN      -

Ohhhh ok. That makes sense :grinning_face_with_smiling_eyes: Good to know, thanks!!

(It was confusing to me because our pro version of the IDE just recently added VSCode sessions as an option in a server environment :see_no_evil: RStudio 1.4 Preview: New Features in RStudio Server Pro | RStudio Blog I was confused how you were using VSCode in the OS version :grinning_face_with_smiling_eyes: )

Nice!! That's perfect, and definitely what you want! What does curl -i localhost:8888 give you from inside the container? Now you want to make sure that process is functioning as expected and the service listening is indeed RStudio.

Then you want to try the same curl -i localhost:8888 from outside the container. If you get a difference, then something is happening in the port-mapping, or you have two processes listening on 8888, etc. (This is admittedly harder if you are on Windows - gitbash might give you a workable curl, though... or you could probably monkey something together with httr or curl in R :man_shrugging: )

Haha, sorry again for the misunderstanding, I was writing in a rush.

So this is what I get with the curl command from inside the container:

curl -i localhost:8888 
HTTP/1.1 302 Moved Temporarily
Content-Type: text/html
Content-Length: 60
Location: http://localhost:8888/unsupported_browser.htm
Date: Wed, 07 Apr 2021 19:58:41 GMT
Connection: close
X-Content-Type-Options: nosniff
Server: RStudio

And then, this is what I get from the WSL (as I use Windows, I relied on the WSL most of my terminal routines):


$ curl -i localhost:8888 
HTTP/1.1 302 Moved Temporarily
Content-Type: text/html
Content-Length: 60
Location: http://localhost:8888/unsupported_browser.htm
Date: Wed, 07 Apr 2021 20:00:19 GMT
Connection: close
X-Content-Type-Options: nosniff
Server: RStudio

It seems that RStudio is there but... for some reason the browser doesn't support the port? I hope it does make sense.

Okay, I think I have been able to make some progress! So, I when I launch the server within the container, I have removed the --auth-none=1 flag. The command now looks as:

usr/lib/rstudio-server/bin/rserver --www-port=8888  --server-daemonize=0

With this, I can see the login page. However, doesn't matter which user/password I try, that I always end up with this scree saying "unable to reach service":
image

At the same time, the terminal throws the following error:

[rsession-rstudio] ERROR system error 13 (Permission denied) [path: /home/rstudio/.local/share/rstudio, target-dir: ]; OCCURRED AT rstudio::core::Error rstudio::core::FilePath::createDirectory(const string&) const src/cpp/shared_core/FilePath.cpp:809; LOGGED FROM: virtual rstudio::core::ProgramStatus rstudio::session::Options::read(int, char* const*, std::ostream&) src/cpp/session/SessionOptions.cpp:232

I check the path to the file, and it does not exist! Thus, I suspect the problem is lying there.