Runtime$ share not configured? RRS feed

  • Question

  • I just provisioned a 2016 Update 1 HPC cluster, and I am attempting to use a SOA service using the latest (at the moment) version of the 2016 SDK [5.1.6088]. I was able to get the system to authenticate my connection, however, when I attempt to write any data to a DataClient, my HPC cluster throws an exception like: "Access to the path '\\\\<HEADNODE>\\Runtime$\\SOA\\340\\7189d647-9e3e-4168-96e1-aeeb45ba1ad9' is denied."

    I have located the directory on the Headnode [C:\Program Files\Microsoft HPC Pack 2016\Data\RuntimeData], and have attempted to give Read/Write permissions to Everybody. I am able to view the share, and i see that the files do indeed get created, but I am unable to write any data. 

    Any idea on what could be the issue? 

    Additionally (probably should be a different question), but I have attempted to create an on-prem installation and joined the nodes to a domain, but is it possible to allow libraries using the SDK to not be from machines in the domain? I have had assorted issues attempting to call the SDK from a non-joined host. One issue that I ran into was when I attempted to instantiate a session using the SDK I get the following:

    Enter the password for '<domain>\<username>' to connect to '<headnode>':
    Remember this password? (Y/N)

    But the password never appears to take. Any ideas why it's asking for the password (when the password is set for the account in the SessionStartInfo object)?

    Wednesday, January 17, 2018 1:01 AM

All replies

  • Hi,

    For the common data issue, may I ask is your cluster domain joined or non-domain joined? Currently common data only support domain joined cluster.

    If yes, could you share your session logs with us? They are located at %CCP_LOGROOT_SYS%SOA\HpcSession_*.bin. You can send them to hpcpack@microsoft.com.

    At the meantime, please try to delete all the contents in \\<HEADNODE>\Runtime$\SOA\, then restart HpcSession service and retry.


    Wednesday, January 17, 2018 4:00 AM
  • Hi Zihao,

    The cluster is domain joined. I believe that I realized what my issue was as far as the permissions go. I was using a call to DataClient, where I passed in the SessionStartInfo which had valid credentials for a user passed in. However, when writing to the file, I believe that the HPC was attempting to use the account of the SDK caller, which was a different user from the one who was defined in the SessionStartInfo object. Changing the DataClient call to use the allowedUsers parameter seems to have helped. 

    However, after changing that call, and cleaning out the Runtime$\SOA, I am unable to get a successful SOA call through, and all I get back is an "Access is denied" error. Exporting the SOA details shows the following messages in the csv files: [HpcServiceHost]: Access denied by BrokerNodeAuthManager. WindowsIdeneity is not recognized."

    Wednesday, January 17, 2018 5:40 PM
  • Hi,

    I have received your logs and noticed that there are two users with same name but in different domains. Could you give us more information about:

    1. In which domain sits your HPC cluster (opgi/apltest) ?
    2. Which user is dataclient caller? Which user is in SessionStartInfo?
    3. Do you mean now you can access the share using dataclient with allowedUsers? What allowedUsers setting you are using?
    4. Under which identity did you launch the session you got Access denied by BrokerNodeAuthManager?


    Thursday, January 18, 2018 4:30 AM
  • 1. The domain sits in the apltest domain. It is a subdomain which has a trust with the opgi domain.

    2. The user which is calling invoking the data client is opgi\Kuser1. The credentials which are being passed into the sessionstartinfo are for users within the apltest domain (apltest\Kuser1 and apltest\Juser2)

    3. Yes, I am now able to access the share since I instantiate the DataClient with the constructor which has the allowedUsers as the Parameter. The allowedUsers parameter is being set to the user which was being set as the Username defined in the SessionStartInfo (apltest\Kuser1 or apltest\Juser2).

    4. I assume that when you say session, you mean a session on the HPC cluster. The accounts that I have been using is apltest\Kuser1 and apltest\Juser2

    Note: I changed the usernames in the forum post, I will send you the actual usernames in a separate email.

    Thursday, January 18, 2018 4:48 PM
  • I was able to resolve this issue. 

    Further background on what exactly happened:
    The service and configuration that I was using in this scenario was developed and configured against HPC Pack 2012. I was able to define that configuration without needing to define any broker settings. Against HPC Pack 2016 (non-update version), in order to get the service to work, I had to rebuild the service against a newer version of the .NET Runtime (4.6.1) with newer dlls from the SDK. I did not need to modify the service configuration file, so I assumed that the old configuration settings were still valid. 

    After a recommendation from the HPC team, I reviewed the configuration against the newer version of the EchoServiceCpp, and attempted to re-define any settings which were missing. (So users need to add the system.ServiceModel/bindings configuration settings). After adding the binding settings to the service configuration file, I was able to authenticate, upload data and send SOA requests again.

    Tuesday, January 23, 2018 5:34 PM
  • Thank you for your feedback and sharing the result.


    Wednesday, January 24, 2018 2:26 AM
  • Changed the WCF service to just run as local system account instead of specifying it in the service panel.
    Sunday, November 10, 2019 6:18 PM