Quick Navigator

Search Site

Unix VPS
A - Starter
B - Basic
C - Preferred
D - Commercial
MPS - Dedicated
Previous VPSs
* Sign Up! *

Contact Us
Online Help
Domain Status
Man Pages

Virtual Servers

Topology Map

Server Agreement
Year 2038

USA Flag



Man Pages

Manual Reference Pages  -  UTFTPD.CONF (5)


utftpd.conf - rules for utftpd




utftpd.conf containes rules for utftpd. It cannot be used by utftpd directly, but needs to be converted through use of utftpd_make(8).


Empty lines in the input are ignored, as are lines which start with a hash sign (#). All other lines may either be V1 format definitions (compatability to versions <0.2.1, see below), class definitions or client definitions.

V1 and V2 format may be intermixed, although i suspect that this will not look too beautiful.

V1 is described in an own section. All other sections deal with the V2 format.


Classes (which other people may or may not call templates) allow to define defaults variable assignments:

      class read_ok {

Classes may inherit from other classes:

      class write_ok { write="/tmp" }
      # a class which only inherits:
      class readwrite_ok: read_ok,write_ok;
      class readwrite_ok2: read_ok {write="/tmp";}

The second and third class are identical.

It’s possible to assign more than one variable to a class:

      class rcs { rcs-co=/bin/co; rcs-ci=/bin/ci }

Here is something which doesn’t work:

      class base {read="123";}
      class c1:base { read+="456" }
      class c2: { read="789" }
          class conflict:c1,c2;

‘c1’ and ‘c2’ conflict: both define ‘read’. There is no simple and clean solution to this problem.


A client definition consists of an address specification, optional class defintions, and variable assignments. An example:

      class base {
      # allow read access to the own config file and the images directory.
      class read_ok { read="${config}${name}:${images}"; }
      # allow write access to the own config file.
      class readwrite_ok:read_ok { write="${config}${name}"; }
      # also allow read access to /etc. Don’t do that in real life, every user can
      # use tftp clients ...
      class etc_ok { read+=":/etc/"; }
      client readwrite_ok { name="localhost"}
      client,etc_ok { name="tirka"}


The ${base} thing you can see above will be replaced by the value of the variable base. It’s an error if that variable is undefined, utftpd_make will stop.

String replacements are done before the strings get written to the configuration database, not in the daemon. Therefore there is no chance to replace something by a client IP address.


There are three forms of variable assignments:

    Simple ’var = value’ assignments

utftpd_make will stop if the variable is already defined.

    ’override var = value’ assignments

utftpd_make will override a old value (if any) with the new one, otherwise it will create the variable.

    ’var += value’ assignments

utftpd_make will append the new value to an old one (if the variable is not already defined it will be created, ‘+=’ then is equal to a ‘=’ assignment.


Adresses may be spefified as follows:

Be careful with the / masks: The slash makes utftpd_make create on entry in the database file for every ip address matches. stands for 65536 addresses, and is certainly a waste of disk space.

The dash also creates one entry for each match, but 194.176.0-31. only creates 32 entries.

Please note that only the first entry in configuration file which matches a given IP address is used. This does not work (but will silently fail, not lead to an error message):

# may write
client {write="/"; }
# allow the whole 194.245.80.* to read
client 194.245.80. {read="/";} will only be able to write, _not_ to read. I consider this a feature: TFTP knows no security at all, so i force you to tell the daemon exactly what to allow. Please note that you should never give read or write access to your root directory.

utftpd_make dislikes duplicate addresses.


utftpd recognizes the following variables in the configuration file:

chroot change working and root directory to the value. Note that utftpd needs to have to necessary rights to do so (this probably means it has still run under root. Use the uid feature to change that. You should not let utftpd run as root.)

dir change working directory. This just changes the way utftpd interprets relative file names (those starting without a /) it receives from clients. Note that you have to specify full paths for the access configuration variables (below) anyway: utftpd uses full qualified file names internally.

uid change user/group ID to the value (which may be a name or a number. Note that, in case of a global chroot, see the utftpd manual page, the system passwd may not be available anymore).

read specifies a list of directories or the daemon may read. Entries are separated by colons (as in $PATH). This may use wildcards.

write specifies a list of directories or files the daemon may overwrite. This may use wildcards.

create specifies a list of directories the daemon may create files in, or files the daemon may create. Note that the create list does not include the write list (or vice versa). This may use wildcards.

sccs-get contains the path to the get command of the SCCS system.

sccs-delta contains the path to the delta command of the SCCS system. If both are given and a SCCS version of a requested file exists then utftpd will try to use SCCS.

sccs-unget contains the path to the unget command of the SCCS system. If this and sccs-clean are missing then utftpd will check in unchanged files. In other words: If one or both of those options are given utftpd will try to not check in unchanged files under SCCS control. This can be an important feature if, for examples, your routers automatically save their configuration to a tftp server every night.

sccs-clean contains the path to the clean command of the SCCS system (this seems to be non-standard). See sccs-unget for a description.

rcs-ci contains the path to the ci command of the RCS system.

rcs-co contains the path to the co command of the RCS system. If both are given and a RCS version of a requested file exists in a RCS subdirectory (meaning RCS/file,v) then utftpd will try to use RCS.

SCCS will be preferred over RCS if both are found. A good place to set the revision control variables is the default target.


When utftpd looks for a configuration variable it will first look for that variable in a cdb entry for (e.g., the IP address of the client), then in an entry for 1.2.3., then 1.2., then 1., and then default.

Only the first occurance of a variable will be honored.

Given the following example:

client {
dir="/" ;
read=${dir}; write=${dir}; create=${dir};
client 194.245.80. {
read="/" ;
client default { read="/tmp" }

The machine may read, write or create the file / or may read, write or create files in a directory with the same name (if that directory exists, of course). It will not be able to read a file /, which all other machines of the 194.245.80.* range are able to do. Everyone else except the 194.245.80.* range may read from /tmp.


V1 format is deprecated. It may vanish some day, and is left just for compatibility with versions of utftpd prior to 0.2.1.

V1 format definitions end at the end of the line. They consist of an address specification (identical to the format used now), a colon, and one or many variable assignments.

Each assignment consists of a list of variables, each separated with a comma, which are followed by a pair of parenthesis containing the value to be assigned (to each of that "list of variables") between them, after which other variable names may follow:

address-specification: VAR11[,VAR12[,VAR13 ...]] ( value ) [VAR21[,VAR22[,VAR23 ...]] ( next value ) ...]

(really all on one line, please).


utftpd(8), utftpd_make(8)
Search for    or go to Top of page |  Section 5 |  Main Index


Powered by GSP Visit the GSP FreeBSD Man Page Interface.
Output converted with manServer 1.07.