Skip to content

SMB Datacommons Access Tutorial

Overview

This Data Attic tutorial guides you through:

It is intended for people new to using SMB Datacommons. It assumes that you have basic knowledge of:

  • Creating Projects in Research Toolkits
  • Creating SMB Datacommons Volumes in Research Toolkits

Before you start

SMB Datacommons Volumes can be created in either DCC Research Groups or in Self-Service Projects in Research Toolkits. Faculty can create Self-Service Projects on their own. If you do not know how to do this, just follow our Quickstart tutorial for creating a project, and Storage Creation and then come back here!

Part 1: Add Data to your SMB Datacommons Volume on macOS

Once your SMB datacommons volume has been created, you should see a mount URL:

Open a Finder window on macOS and hit command+k (alternatively, you can also click Finder > Go > Connect to a Server...). Enter the volume path and select Connect.

You will need to enter your credentials to access the volume:

Make sure that you have "Registered User" selected. Enter you netID for the "Name" field and your netID password in the "Password" field, then select "Connect." You should be connected to your SMB Datacommons volume.

Part 2: Add Data to your SMB Datacommons Volume on Windows VM

(Before beginning the steps below, you need to have both "Data Commons Scratch Space" and a "RAPID" VM setup within the Research Toolkits interface.) The following will make your "Data Commons Scratch Space" available for access directly on your RAPID VM

Windows VM

  1. Login to your VM via RDP as you normally would
  2. Launch "File Explorer"
  3. On the left pane of the display, right-click on "Network" and select "Map network drive..."

  4. In the "Map network drive" dialog box, for "Folder:" enter the mount URL listed for the SMB Datacommons volume in the Research Toolkits webUI, minus the "smb:" portion, and with all slashes reversed, e.g.:

    \\oit-nas-fe13dc.oit.duke.edu\rem-test_DEMO_rem_test

  5. Make sure the "reconnect at sign-in" checkbox is checked and then hit "Finish"

  6. When prompted for credentials, specify your username as "WIN\netID", replacing 'netID' with your netID (e.g., WIN\ai36) and your password as whatever your netID password is
  7. You should be left at a "File Explorer" window that shows the contents of the share in the right pane and has the mapped drive highlighted in the left pane

NOTE: the 'rapiduser' account DOES have "write" rights on the above mapped drive

NOTE: the drive WILL remain mapped and accessible through disrupted RDP connections (and thus re-connections), but will NOT remain mounted across reboots of the VM (after reboots, repeat steps 4-6 above OR double-click on the previously mapped drive (that now has a red X through it) and you should be prompted to re-enter your credentials (step 6))

Part 3: Add Data to your SMB Datacommons Volume on Linux VM

  1. Login to your VM via SSH as you normally would and issue the following commands...
  2. [For Ubuntu ONLY] sudo apt-get -y install cifs-utils
  3. [For RHEL7 ONLY] sudo yum install -y cifs-utils
  4. sudo mkdir /mnt/test-scratch (or whatever path you wish it to be mounted at on the RAPID server (be sure to also change that path in the subsequent steps))
  5. sudo mount -t cifs {path listed for the Scratch Space in the Research Toolkits webUI, minus "smb:" portion} /mnt/test-scratch -o username={your_netid_here},noexec,domain=WIN (see example below)
  6. Enter your netid pw when prompted at this point
  7. ls -al /mnt/test-scratch/ (which should now display the contents of that share)

EXAMPLE FOR LINUX:
sudo mount -t cifs //oit-nas-fe13dcpub.oit.duke.edu/scratch/inghamtest_test-AWI-DC /mnt/test-scratch -o username=ai36,noexec,domain=WIN

NOTE: the 'rapiduser' account does NOT have "write" rights on the above SMB/CIFS mount. In order to have anything greater than read-only access you will need to either "su" to root or run commands (such as vi) via "sudo" (as the "root" user DOES have "write" rights on the share)

NOTE: the share WILL remain mounted through disrupted ssh sessions (and thus re-connections), but will NOT remain mounted across reboots of the VM (after reboots, repeat steps 5&6 above)