|CSE Support||Printer Friendly Version (PDF)||CSE Home||About Us||Search||Contact Info|
Under one drive, O:, on a Windows workstation you can access shared files, folders, and directories that reside on a wide variety of CSE file servers, both Windows and UNIX. This includes, for example, all Windows and UNIX home, project, web and course directories.
Microsoft's Distributed File System, or Dfs (pronounced "doofus")(1), provides a stable, location-independent(2) naming scheme for all shared files you need to access when using Windows. A single "UNC"(3) share, or a single drive mapped to such a share, is able to contain files and directories on any number of file servers. It works by looking up the actual locations of remote shares in a table called the Dfs map, in a way very similar to automount mapping in UNIX (see UNIX Automount Mapping in CSE).
The UNC name for all Dfs files in CSE begins with \\cseexec\cs.(4) By convention \\cseexec\cs will automatically be associated with drive letter O:. If this is not the case you can use one of the file manager tools to map \\cseexec\cs to O:, or you can enter the command `net use O: \\cseexec\cs'.
If you are using a computer that does not use CSE's name servers, for example your personal computer at home, you will need to map the fully qualified name, \\cseexec.cs.washington.edu\cs. Important: you will also need to make sure your home computer is configured correctly, as outlined in Network Location Cannot Be Reached.
Microsoft's documentation on Dfs can be accessed at
The following table shows the topmost directory structure of Dfs directories in the department.
Dfs path prefix Comment O:\nt\rprojects Research projects \iprojects Instructional projects \runs Research unsupported area \iuns Instructional unsupported area \courses NTFS instructional course directories \dist-area Software distribution area \office Research office area \support Research support area \images PC rebuild images \grail Grail (graphics) projects and data \cygwin Cygwin installation \homes\ifaculty Instructional PC faculty home dirs \rfaculty Research PC faculty home dirs \istudents Instructional PC student home dirs \rstudents Research PC student home dirs \istaff Instructional PC staff home dirs \rstaff Research PC staff home dirs O:\unix\projects Same as /projects, research UNIX \nfs Research NFS Gateway \vole Instructional TA NFS Gateway \homes\gws Same as /homes/gws, research UNIX \iws Same as /homes/iws, instructional UNIX \sgi Same as /homes/sgi, grail servers \sys Same as /homes/sys, system servers O:\cse Like /cse, research UNIX O:\sources Like /sources, research UNIX
Things to notice in this table:
Microsoft has designed Dfs to be fault tolerant by allowing the Dfs map to be published to the "Active Directory" of a Windows domain. In CSE it is replicated among the domain controllers of "cseexec.cs.washington.edu", our top-level domain. Thus the root, \\cseexec\cs, refers not to a host and share, but to a "volume object" in the active directory.
Until a few years ago a Dfs map in the active directory was restricted
to about 1000 entries, so we used to run a standalone Dfs server
reachable by the name
The standalone server still exists. Currently Dfs maps in cseexec's
Active Directory are replicated on server
ntdfs, and reachable
by \\ntdfs\cs or \\ntdfs.cs.washington.edu\cs.
Note: Previously Dfs files could also be accessed via \\ntdfs.cseresearch.cs.washington.edu; however, that is no longer the case.
If you have not already given your CSERESEARCH or CSEPCLAB Windows credentials (e.g. you are using your personal laptop), you should be prompted for credentials(5) when you attempt to map \\cseexec\cs to drive O:. When entering credentials prefix your username with the CSE domain you want, e.g. CSEPCLAB\jouser, and enter the corresponding password.
If you are having problems accessing a Dfs path, you may be experiencing one of the errors described in this section.
Note: See An Alternative to Mapping Files on Your Home System for a way to finesse all of these access problems and yet still be able to easily transfer files between CSE systems and your home system.
If you see
...not accessible. The network location cannot be reached.
...not accessible. The network name cannot be found.
...not accessible. The specified network name is no longer available
In some cases you may have successfully mapped \\cseexec.cs.washington.edu\cs to a drive letter from a client outside the local CSE network, and now you are trying to drill down into a folder under that drive letter. You can usually fix this by reconfiguring your workstation by making sure that its "DNS suffixes" include "cs.washington.edu." To do this follow the procedure in Adding `cs.washington.edu' to your DNS suffixes. Note that after you do this you will need to disconnect and and re-map \\cseexec.cs.washington.ed\cs.
In rare cases these messages could also mean that one or more network services are down. Contact support@cs if you have questions.
On Windows servers, each file and folder (directory) has read/write
permissions assigned to individuals and/or groups. In the case of
UNIX, each file has permissions assigned to its owner, one group, and
the world (everyone). See
http://www.cs.washington.edu/lab/support/web_write.html for a primer on UNIX file permissions.
Therefore, your access to a file or directory is based on your login name and group memberships, which in turn depend on your job and the projects you are working on.
Login names, group names, and group membership are "universal" among all CSE systems, whether Windows or UNIX.
...not accessible. The folder was moved or removed.
...refers to a location that is unavailable...
...not accessible. The specified network password is not correct
...not accessible. Login failure: unkown user name or bad password.
Furthermore, you must also have an account on each file server that Dfs attempts to access. See You Need a UNIX Account to Access UNIX File Systems for further info about UNIX file servers.
...not accessible. Windows cannot find the network path.
If your ISP is blocking the port, there is a way around this problem, but at present it works for windows file servers only. Note that if you can map \\cseexec.cs.washington.edu\cs to a drive letter, that is proof that your ISP is not blocking the file sharing port. If you cannot do such a mapping, see www/lab/sw/nt-inegration/remoteaccess/winremote.html for directions on how to "tunnel in" to a Windows file server(7) and get around the fact that your ISP is blocking a port.
...not accessible. The account is not authorized to log in from this station
...not accessible. The format of the specified network name is invalid
This is not a problem with all Windows versions since Windows 98. But it can be (and is) a problem with other types of clients, e.g. the stuff that comes with Mac OS or Linux. Just because you can access remote files on Windows servers and UNIX (via Samba) does not mean you will be able to drill down into \\cseexec\cs beyond the so-called "junction points" that are derived from the Dfs map.
For example, you may be able to get to \\cseexec\cs\unix\homes\iws just fine, but not to your home directory one level down. In some cases third party software is available to make your system Dfs-aware, e.g. http://www.thursby.com/products/dave.html for MacOS users.
You can map any directory under the Dfs root
to a drive letter.(8) For example,
directory UNC path via Dfs is \\cseexec\cs\unix\homes\gws\jouser.
She will find it very convenient to map this to a drive letter using one
of the file explorer tools or, for example, a command:
net use J: \\cseexec\cs\unix\homes\gws\jouser
Is this better than mapping J: to \\barb\jouser? YES. Why? Because jouser's so-called "barb home directory" is most likely not on barb---and neither is yours.
By mapping your home directory with Dfs you ensure that you deal
directly with the UNIX server your home directory resides on; by mapping
barb you slow things down, because the always overloaded
barb is then forced to act as an intermediary between your PC and
your UNIX home directory.
If you need to know what file server a particular directory is on, use one of the following procedures:
In order to access a UNIX file from Windows you need to have an account on a UNIX server that can access that file. This is no different from Windows, where you also need to be authenticated in the domain of a Windows server to access its files.
So, for example, if you want to access O:\cse\www\ the remote
host, in this case
www, needs to see an
entry for you in its passwd file. Note that this does not necessarily
give you login privileges to the remote UNIX host, as you could have a
"nologin" entry that only allows remote access of files. Actually
www is not a good example, since all faculty, staff, and grads
have passwd entries on the web server. However, this is not the case
for all UNIX file servers, e.g. the Grail laboratory's research servers,
on which you probably do not have an account.
Note: To find out the hosts where you have login accounts, use this
Of course the easiest way to change permissions on UNIX files is to log into a UNIX system and use the chmod command (for which there's a man page), but it certainly can be done using the Windows Explorer tool as well.
For files, go to the "Security" window by right-clicking on the file, choosing "Properties" and then clicking on the "Security" tab. You will see three entries under Name: "Everyone", a group name, and a user name, displayed as follows:
<multiple profile icon> Everyone <single profile icon> username(hostname\username) <multiple profile icon> groupname(hostname\groupname)
To change permissions, clear all the boxes and click "Read" and/or "Write". If you want execute permission in addition to read, click "Read&Execute". If you *only* want execute permission, you'll need to click on "Advanced" and choose only the "Traverse Folder/Execute" box; the procedure to follow is the same as that outlined below for setting folder permissions.
Be sure NOT to click any boxes in the "Deny" column.
For folders (directories) the process is a bit more complicated, since (because of bugs in the Windows explorer tools, even on XP) none of the permissions are displayed in the main Security window. So, you'll need to click on "Advanced..." in all cases.
On the "Permissions" tab of the Advanced window you will see six entries. You will only be concerned with the three entries that have "This folder only" in the "Apply to" column. These three entries will be as described above: "Everyone", a group name, and a user name. Choose the one you want to change and click "View/Edit". Yet another window will pop up! (This is Windows, after all.) This window shows the exact permission settings for the folder. To set permissions:
As for files, in no case touch anything in the Deny column.
There are two additional (hidden) directories under O:\unix (or \\cseexec\cs\unix), namely nfs and vole.
A path name such as O:\unix\nfs\nfspath enlists the aid of a research NFS "gateway" UNIX host, where nfspath is a UNIX NFS path (with /'s replaced by \'s). Similarly, O:\unix\vole uses an instructional NFS gateway.
O:\unix\nfs\ should only be used for the rare situation in which an NFS file server you need to get to is not also a Samba server, or in case you do not have an account on a UNIX NFS server but you can access files on that server via NFS.(10) Use O:\unix\nfs\ only if you have to, because the price you pay is that all data from and to a file's location must make an additional network hop via the NFS gateway host.
The other gateway machine,
vole, is used exclusively by undergrad TAs who need access to their course web files, found under directory O:\unix\vole\cse\www\education\courses. Undergrads must use a gateway because they do not have accounts on the web server, www.
In Windows XP, here is what you need to do (the procedure is similar in W2000, but there may be a few minor differences):
(There may be more ways - I only have two XP systems for which there are 3 ways!)
properties -> internet protocol (TCP/IP) -> properties -> advanced... -> DNS
UNIX users in CSE are already familiar with the concept of Dfs, since it is exactly the way NFS automounting works. In NFS automounting, the actual locations (host:/directory) are listed in a table called an automount map in which each location has a corresponding key. For example, here are a few entries from the /projects map on the research UNIX systems:
Key Maps to ai2 fury:/fury13/ai2 robotics dark:/dark10/robotics grail20 doppio:/doppio1/projects
/projects/ai2/...on any host results in an actual access to
/fury13/ai2/..., located on host
fury. NFS automounting on the research UNIX systems is set up with multiple roots:
You need to transer files to/from your home system, but you cannot or do not
wish to go through the fru-fra(11) of getting your system to map remote drives. What can you
do? Answer: Use remote desktop to log in to a CSE system (either your
desktop system in Allen or one of the time-sharing terminal servers),
and use the "Redirection of Local Drives" feature. All is described
Microsoft Dfs should not be confused with Transarc's Distributed File System product called DFS (pronounced "dee eff ess", http://www.transarc.com/Library/whitepapers/efs_strategy.html) which has been around for many years. DFS is a component of DCE (the Distributed Computing Environment), promoted by the Open Group, previously known as the Open Software Foundation. To distinguish its distributed file system from the original, as well as to avoid treading on Transarc's trademark, Microsoft has chosen to spell Dfs with lower-case "f" and "s". In Transarc's DFS the main goal is to provide a universal naming scheme for all files.
In location-independent file sharing the name of a file is independent of both the file's and the user's physical location, contributing to ease of file sharing and resource management.
One definition of "UNC (Universal Naming Convention) name" (from the Windows 2000 on-line Glossary) reads as follows: "A full Windows 2000 name of a resource on a network. It conforms to the \\servername\sharename syntax, where servername is the server's name and sharename is the name of the shared resource. UNC names of directories or files can also include the directory path under the share name with the following syntax: \\servername\sharename\directory\filename."
This used to be \\ntdfs\cs; see Fault Tolerance to know why it changed.
It may happen that you are not prompted for credentials; in this case you need to click "Connect using a different user name" in the "Map Network Drive" window in order to enter your credentials.
Port 445 is used for Windows file sharing. If your ISP confirms that they are blocking this port, your only recourse is to complain to them
Note that cseexec.cs.washington.edu is not a file server: you must know the exact names of the Windows file servers where your folders reside and map directly to those servers.
You can even do this with NT 4.0, but only
for Dfs (
barb is the departmental main computer
An NFS server does not require the user to have a local UNIX password entry in order to access its files.
Dealing with your port-blocking ISP (Network Path Not Found) or reconfiguring your home system (Network Location Cannot Be Reached).