R-Code read and write to CIFS drive getting errors

Hi all,
I've just started a new job 2 weeks ago and I've inherited an R Studio installation that is not working.
I've been through the logs etc and the only error I can find is

rserver[2178]: ERROR system error 74 (Bad message) [description=error:0407106B:rsa routines:RSA_padding_check_PKCS1_type_2:block type is not 02]; OCCURRED AT: rstudio::core::Er
ror rstudio::core::system::crypto::rsaPrivateDecrypt(const std::string&, std::string) /root/rstudio/src/cpp/core/system/PosixCrypto.cpp:330; LOGGED FROM: void rstudio::server::pam_auth::::doSig*
nIn(const rstudio::core::http::Request&, rstudio::core::http::Response) /root/rstudio/src/cpp/server/ServerPAMAuth.cpp:326*

The only thing I might have come up with is the files are stored on a CIFS share tot he REDHAT server and written back there. It appears the right back is causing issues.
I've put in a request for windows patches applied around the time it was reported (5 weeks ago).

Does anyone have another aspect I can look at, or point out the thing I have missed.

Thanks David

OK, reaching bad to the dim recesses of the mid-90s when I used to do this sort of stuff on Windows NT, it looks to be that the big picture is

  1. rserver was attempting to authenticate, possibly to access a network resource, with an rsa public key, which threw error:0407106B:rsa
  2. It was unlikely to be an authentication to rserver, because that is more likely to be logged as a user, rather than a system error.
  3. The authentication process was occurring over an http protocol connection via the cloud or an internal TCP/IP route.
  4. If I'm correct, this is a configuration problem either with rserver or the target server or an intermediate server, such as a proxy server.
  5. That suggests a traceroute to the target server.
  6. Packet loss through the routing could result in a corrupted key exchange.
  7. First responder should be the network administrator.

I've had a look and the only RSA thing available is the user credentials. All the source and destination is CIFS shares and I can see and open some files via bash (using more or vi) however some have read write errors.
I'm investigating Windows patches for possible file name errors

Thanks
Dave

1 Like

So we have managed to run a linux only file system and it works fine.
There is something the matter with the CIFS share mount.

Thanks for your suggestions

1 Like

Great. Please mark your answer as the solution for the benefit of those to follow.

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

Hey TechnoRat,
I don't know enough and learning fast but that is an aspect I hadn't considered, but makes sense when you say it like that.
I'll look into it closer.

Thanks
Dave

1 Like

Wow thanks for your prompt reply,

As I understand it a previous SYS admin installed this in a Proof of Concept, and zero doco.
It is also on a shared server with other CORE applications.

I have asked for a list of sources, and will probably spend today trying to figure out how to drive the UI, so I can test.

Thanks again

1 Like

A well behaved credentialing routine should fail gracefully if the root cause is the client's key, since that is expected to happen more or less routinely.

That promotes the server as a more likely root cause. If its key is inoperable through corruption or expiration, if issued by a certificate authority, the routine should flag it as a systems error.

Again, I apologize for any rabbit holes that I might lead you to due to the very long time since I've operated a certificate server.

You have my complete sympathy!

If that doesn't get resolved easily, an alternative is possibly one or more of the SAAS cloud options. For proof-of-concept the \beta no fee version might allow evaluation sufficiently to decide how to move forward to either self-hosting or one of their commercial cloud-hosted version. (I don't have any financial relationship with RStudio, so just sayin'.)

1 Like