Accessing your UCLA CSD home directory via Samba on Windows

These instructions will only work if you already have an account with the UCLA Computer Science department. I have tested this on my HP laptop running Windows XP Home SP2 for accessing my home directory on cheetah.cs.ucla.edu. Here are the steps you need to take:

1. First make sure that your login username on your local computer is the same as your CSD login. This makes things much simpler. If this is not the case, see here. You will probably have to ask help@cs to map your local username to your CSD login.

2. Change your Samba password to be the same as the password for your local login account. You can do this by logging in to any department server, e.g., cheetah.cs.ucla.edu, and issuing /usr/local/bin/smbpasswd -r toucan. Note that your Samba password is completely disjoint from your regular CSD account password. If you have any problems, email help@cs and ask them to reset your Samba password.

3. Now login to the CSD server using your regular CSD account username and password. I recommend using Putty for that purpose, a free Windows ssh client that you can download here. Once logged in, you can view the available Samba shares by issuing /usr/local/bin/smbclient -L toucan (it will ask for your Samba password). You should then see a Disk share named after your account login; this corresponds to your home directory on the server.

4. If you are on the CSD network, you can now map this share to a local drive on your computer. If you not on the CSD network, go to step 6. Open up My Computer, click on "Tools -> Map Network Drive...", choose a drive name and specify the folder as \\<server>\<login>, for example \\cheetah.cs.ucla.edu\nikitas. Check "Reconnect at logon" if you want the drive to be mapped every time your computer boots up. That should do it. You should now have access to your home directory through the local drive you just mapped.

5. If you are not on the CSD network, things get complicated. You have to create an authenticated tunnel via which you will gain access to your home directory at school. To do that, you must create a connection with an ssh tunnel from port 139 on your local computer to port 139 on your department server, e.g., cheetah.cs.ucla.edu. If you are not sure what an ssh tunnel is or how to create it, here is a short tutorial on how to do it with Putty. However, even after creating the tunnel, you still won't be able to access your home directory. This is because port 139 on Windows is already bound by the NetBIOS services. One (ugly) solution to this is to open a command window and issue net stop server. This will stop the conflicting services, at the expense of losing some functionality, e.g., browsing computers on the local network. For a more elegant solution, see step 6. If you are OK with that, you can now open up Putty and log in using the connection you created before that activates the tunnel, forwarding port 139 on your local computer to port 139 on your department server. Then simply repeat the actions in step 5, substituting 127.0.0.1 for <server>, and you should be good to go.

6. A better solution for avoiding the conflict with the NetBIOS services is described here. That page also contains some more information on Samba tunnels and potential problems that may come up. In a nutshell, the idea is to add a virtual adapter to the local machine, and disable the NetBIOS services on that virtual adapter only (which will leave your regular network interface alone). Then, instead of forwarding port 139 from the local computer to the department server, you will forward port 139 of this virtual adapter to the server. In Putty, for instance, the tunnel should read as "L10.0.0.1:139 cheetah.cs.ucla.edu:139". This will work just fine because the NetBIOS on the virtual adapter are disabled. Note that you don't necessarily have to create two tunnels, one from the virtual adapter to the local machine and another from the local machine to the server, as the aforementioned page suggests. After doing so you can map your share using \\<virtual_adapter_address>\<login>. Unfortunately, this solution requires you to manually set the gateway and DNS server settings for the virtual adapter to the ones for your regular network interface (which are probably set by DHCP when the interface first connects to the network). Hopefully, these do not change too often though.

Questions? Email me at

Go back to the main software page.