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.

Interesting!! Yeah, I forgot that we have a User Agent check that makes things tricky to test from curl

I am glad to hear you have made progress though! Does the user's home directory (/home/rstudio/) exist? The rest of that path should be fine, but the home directory does have to exist (and have proper ownership) for RStudio to function properly. You can test the permissions / ownership on the entire directory tree with:

namei -l /home/rstudio

So, I think I made another step of progress. At the moment, I am able to log in to my laptop without problem. However, when I try to do the same in the EC2, I cannot, unfortunately, log in. The message that I see in the logs are:

[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] userconf: executing...
usermod: user 'root' already exists
groupmod: group 'root' already exists
USER is now root
[cont-init.d] userconf: exited 0.
[cont-init.d] done.
[services.d] starting services
[services.d] done.
14 Apr 2021 19:02:03 [rserver] WARNING User root could not be authenticated because they did not meet the minimum required user id (1000). The minimum user id is controlled by the auth-minimum-user-id rserver.conf option.; LOGGED FROM: bool rstudio::server::auth::validateUser(const string&, const string&, unsigned int, bool) src/cpp/server/auth/ServerValidateUser.cpp:94
14 Apr 2021 19:02:14 [rserver] WARNING User root could not be authenticated because they did not meet the minimum required user id (1000). The minimum user id is controlled by the auth-minimum-user-id rserver.conf option.; LOGGED FROM: bool rstudio::server::auth::validateUser(const string&, const string&, unsigned int, bool) src/cpp/server/auth/ServerValidateUser.cpp:94
14 Apr 2021 19:03:08 [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
14 Apr 2021 19:03:09 [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: int main(int, char* const*) src/cpp/session/SessionMain.cpp:1961
14 Apr 2021 19:03:50 [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
14 Apr 2021 19:03:50 [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: int main(int, char* const*) src/cpp/session/SessionMain.cpp:1961

In a way, I find a bit strange that running the container locally and in the EC2 with the same command gives a different result. In any way, my current alternatives are two, so I would like to hear what could you advise me:

1- Remove the authentication when calling Rserver. I am happy to proceed as our system already has an authentication method. Still, I suspect that removing the authentication is not as simple as adding --auth-none=1, or is it? I have already tried but ends in the same unable to reach service.
2- Adding the user manually when building the image. I thought I already did that when I configured the file usercof.sh based on this template, yet when I write my user name test123, password test123, then it says "Unauthorised User".

I will appreciate very much any piece of advice on how to solve this issue.

I haven't had a ton of time to dig into this, but a few off-the-cuff thoughts:

  • the error WARNING User root could not be authenticated because they did not meet the minimum required user id (1000). The minimum user id is controlled by the auth-minimum-user-id rserver.conf option. is a standard one that suggests you were trying to authenticate to RStudio with a user whose uid is < 1000. As the error suggests, this can be reduced with the auth-minimum-user-id setting. You can check a user's uid (for example with username myuser with:
id myuser
getent passwd myuser
  • I am not familiar with userconf.sh, but "Unauthorized user" sounds a lot like the password is wrong. I typically test on the command line with:
# from a non-root user
su myuser
# enter user's password to verify it works

If this does not work, then I set the password manually (or investigate my user definition flow):

passwd myuser
  • I am also unfamiliar off-hand with disabling authentication, but will try to take a look later. Something to keep in mind is to try with an Incognito window to ensure cookies are not playing a part in your interactions.

I hope that helps!! I also hope to take another look at this later, but it has been a crazy couple of weeks for me!

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.

If you have a query related to it or one of the replies, start a new topic and refer back with a link.