Redirecting a Samba share to another server

In this post I'll describe how to configure Samba to redirect a share to another server. A typical example when this might be useful is as follows. You have a share, say \\server\work that you need to migrate to new hardware, so that it becomes \\newserver\work. However, you don't want all your users to remember that the files are at a new location. You'd like your users to continue using the old address \\server\work and be transparently redirected to \\newserver\work. This is possible with MS DFS (distributed filesystem) support via msdfs proxy directive. It seems like a more obscure directive not very well documented and described, so I'll try to report my experience with it.

The first thing to do is to enable MS DFS in Samba on the global level by specifying:

host msdfs = true

in the [global] section of smb.conf.

Then in the section for your share, you remove the path directive and insert two MS DFS-related directives, msdfs root and msdfs proxy:

[work]
msdfs root = true
msdfs proxy = \newserver\work

Note a few things about this configuration:

1. You MUST NOT have the path directive in the share definition
2. The value of msdfs proxy directive is the new location of the share to redirect to; notice though, that's a single backslash in the beginning of the value, NOT the double backslash you could have expected!

That's all, now \\server\work transparently redirects to \\newserver\work. Clients may need to be rebooted to start working properly with the redirected share. In my experience, clients can't access the share right after the reconfiguration, but it starts working after some time (not sure how much time) or after the client reboots.

Per-client-IP configuration for VSFTPD

Recently I needed to configure VSFTPD FTP server to behave differently depending on the client IP address. Specifically, the task was to limit the number of connections to no more than 3 per client IP, but lift this restriction for one specific IP address (which was our own office address). The per-IP limit itself is easy to implement with max_per_ip configuration setting (see VSFTPD FAQ). The trick was specifically in making our office address the exception to this limit.

While per-user configuration is easy to implement with user_config_dir setting (and it is described in the FAQ), per-IP configuration is less obvious, so I thought I would document my findings.

The path to per-IP configuration lies via interaction with tcp_wrappers. Just in case you don't know, tcp_wrappers is a tool for filtering incoming network requests, and VSFTPD makes use of it. So, the first thing to do, is to enable tcp_wrappers support in VSFTPD, by making this setting in vsftpd.conf:

tcp_wrappers=YES

Then proceed to enter the default configuration in the main vsftpd.conf file. In my case, I set max_per_ip to limit connections per IP address:

max_per_ip=3

The next step is to configure tcp_wrappers. Add a line similar to the following to /etc/hosts.allow file:

vsftpd:1.2.3.4/255.255.255.255:setenv VSFTPD_LOAD_CONF /etc/vsftpd/vsftpd.conf.special

This must be a single line, even though Blogger may wrap it. It consists of 3 fields, separated bu the ':' character. The first must be vsftpd. The second contains your "special" IP address for which you want to enable a special configuration. As shown above, it may include a netmask so that you can apply the special configuration to a subnet (see man page for hosts.allow for details). Finally, the third field instructs tcp_wrappers to set an environment variable VSFTPD_LOAD_CONF to the name of a configuration file that will apply to your special IP address(es). The name of the variable must be exactly this; the value may be any filename you like. Once tcp_wrappers set this variable, VSFTPD will load the configuration file specified in it for the IP address(es) from the second field.

So, in the additional configuration file (in my example, /etc/vsftpd/vsftpd.conf.special) you can override everything you want for your special addresses. In my case I just needed to turn off per-IP restiction:

max_per_ip=0

That's it. I find it rather convoluted, but it works and achieves a useful purpose.