If you are using a computer that is not on the AD domain, you will need to login using your kerberos username and password. This is done by clicking "Connect using a different user name." or "Connect using different credentials" on some newer machines. If you simply click "Finish" without entering your info, Windows will send your current username and password.The path to the x: drive is.

If authentication is required (for all computers that are not on the ad domain), be sure to prefix the user's kerberos name with ad\. E.g. if the user is jsmith, the username field should contain

ad\jsmith

and the password field should contain the user's normal kerberos password.

Mounting in OS X

To map a network drive in OS X:

Open the the "Connect to Server" dialog by clicking Go->Connect to Server under the finder or by using the hotkey Apple+K.

Mounting in BU Linux 5

Mounting in BU Linux 6, Ubuntu, etc.

Here are three ways to access the network share drives. SMB and SSHFS are easiest, permanent mounts and NFS are hard.

(1) SSHFS

It's a pain to mount kerberized shares on other linux distributions, so we strongly recommend that you use SSHFS. You will need to enable fuse in the Kernel (under Filesystems) and modprobe fuse if you compiled it as a module. The sshfs package is usually called fuse-sshfs. It is not a part of the BU Linux repositories, but was a part of Gentoo, for example. Your experience may vary. An RPM can be found here:

Be sure to use cifs as the drives are hosted on Windows Server 2003 and to not provide your user account information directly in the /etc/fstab file as anyone on the sudoer list would be able to see this information.

To add to the last instruction, a valid line to mount a share ( in this case a research share ) looks like the following:

where eng_research_something is replaced with a valid share path and credentials=/home/your_user_name/.credentials is the file that contains your username password ( see the Ubuntu example ). It seems that for all users of a non-AD (not tested on an AD connected machine so - someone else can verify) connected machine it may be necessary to add "allow_other" to the mount options. One important thing to note is that permissions on the folder will be those of the user specified in .credentials - playing with the permissions on the client side (changing the options in fstab) may conflict with those granted by the kerberos account. To avoid these concerns, consider using SSHFS, which is easier.

To quickly get a list of available net-bios paths ( this is the path that will be used in your fstab):

bash# smbclient -L engna1 -U ad\\your_username

And to find a list of folders one can also use

showmount -e engna1

Showmount is included in nfs-utils. Note that you can't mount the network shares as nfs - they must be cifs, but showmount is a nice tool to quickly list remote folder names.

Mounting from Off Campus

To mount the network shares from off campus, you'll have to connect to the VPN before the above instructions will work. The instructions for doing so on a number of different operating systems are maintained by IS&T and can be found here.

Quota Limits on Network Drives

If you find that jobs that write large amounts of data, such as Cadence simulations, are failing inexplicably, check if you're out of space in your home directory. Note that the X: (/ad/eng/uses/u/s/username) drive has a hard quota limit of 10GB per user and cannot be updated. If your lab has an /ad/eng/research (W:) drive, it is recommended that you put large amounts of data here instead. Note that large amounts of data are often included beneath dotfile directories (those that start with a '.') which may just be full of unneeded temporary data. On Linux systems with the AD drives mounted, such as on lab machines or on enggrid, you can check your quota usage by running "quota -s". On Windows, you should right-click on the top-level of your home directory and choose "properties", and your drive usage will be calculated (this may take a while as it counts up).