Distributed File System (DFS)
FRS vs. DFS vs. DFS-R
FRS (File Replication Service) is used to replicate SYSVOL in Windows Server 2000 and 2003. It is slowly being replaced by Microsoft with DFS-R (Distributed File System Replication) in newer versions of Windows Server.
Samba does not yet include SYSVOL replication, neither with FRS, nor with DFS-R.
DFS-R is often viewed as subfunction of DFS (see below), and both are often used together, but they can also be used completely separately: DFS with multiple targets can be used without DFS-R (if the folder contents are updated with some other method), and DFS-R can replicate shared folders that are not DFS-targets.
Samba partially supports DFS, but not DFS-R yet.
DFS (Distributed File System) is a feature that provides several functions: alternative name space, load balancing, and automatic failover.
Technically DFS provides access to a shared directory that contains no files, only junctions, and optionally subdirectories with more junctions. Junctions are similar to soft links as known from Unix file systems, but ones that point to shared directories, and they can also point to shared directories on other servers. The clients first ask the DFS server for the junction, then access the file server where this junction points to.
The main use of this is to create an alternative name space (directory tree view), that hides details of the underlying infrastructure from the users. The paths that the users see (called DFS names) do not change when servers are renamed, or when some of the directories are moved to a different server. The administrators can simply replace the outdated DFS name with a new one, that points to the new target.
A DFS name can optionally point to more than one target (i.e. tell the client several alternative junctions to different shared folders). In this case clients can access either of the targets. This provides load balancing, and automatic failover to another server, if one server fails.
DFS can be either stand-alone, or domain-based.
The stand-alone variant runs on one single server and causes the DFS names to contain the name of that server, they look like shares that are provided by that server.
The domain based setup causes the DFS names to contain only the name of the domain, not the name of any specific server. Several servers in the domain can act as DFS servers in parallel. Clients automatically select one of the DFS servers and send their queries to that one.
Samba seems to only support stand-alone DFS so far.
The method to set up the stand-alone variant with Samba is described here:
In short it requires in the config file smb.conf the global option
host msdfs = yes
and in one share declaration the two options
path = /export/dfsroot msdfs root = yes
Then in the specified path create entries by running commands like
ln -s msdfs:storage0\\share0 linka ln -s msdfs:server1\\share,server2\\share linkb
The first example defines one target, the second example creates two alternative targets that share the same contents.
Windows clients will see these as junctions.
There is currently an important limitation in the Samba implementation: Neither the path dfsroot specified in the DFS share, nor any of the share paths in the ln-commands must contain upper case characters. The links might be allowed to contain upper case characters.
There is currently (June 2014) an ongoing discussion in the mailing list whether or not domain based DFS, load balancing, and failover are currently supported by Samba 4.
Load Balancing and Failover are implicitely supported, because if the server tells the client more than one target (which is supported), the client will randomly choose one of them. If it fails to connect to that, it will automatically switch to another one.
The variant domain-based DFS seems to be not supported.
DFS-R (replication) is definitely not yet implemented.