The Coda Administration and User Manual

of Kiss Coda Wiki

The original Coda Administration and User Manual has not kept pace with development, and is now misleading in places. Most of the answers are available in the mailing list archives.

If you find something you think should be here then please fill it in.


Getting Started

In the original the first paragraph of this secton has been moved to the end of the page.


Perhaps this belongs in Troubleshooting? When using clog as directed on one client I got kerberos-related error messages, and login failed. Using ‘clog -coda username’ sorted it. The client was a Gentoo linux box with the ‘kerberos’ USE variable set, so when coda was installed it was compiled with kerberos support. (note kerberos support if not using the modular clog is broken)

Common Scenarios


System Overview

Configuring Kernels for use with Coda

Shouldn’t this go under the next section?

Up-to-date Coda support is present by default in Linux 2.6, FreeBSD 6..8, NetBSD >= 2.0.

VFS Interface

No known error. Only here to stop Wiki numbering getting out of step with the original.

Configuring a Linux Kernel

The original document only goes as far as 2.1 series kernels. Coda support is available in both 2.4 and 2.6 series kernels.

Linux 2.4 default Coda module is outdated and can not be used without patching.

Linux 2.6 has a good Coda module which is present by default (at least in Debian, Knoppix, Red Hat EL, SuSE and probably in any distribution which is not purposedly cut down to be very “minimalistic”).

The Coda module is small (about 50k on my machine), so no reasonable packager would spare on it. For comparison, nfs module on the same system is about 90k.

If you compile Coda module yourself, do not enable “compatibility” with older Coda, it does not help anything nowadays. The fids shall be 128 bits, not 96 as it was in the past.

Depending on the distribution you may need to add “coda” to /etc/modules or alike and/or “mknod /dev/cfs0 67 0”.


You’re lucky! the coda ebuild does it all for you (it did for me with coda-6.0.8 anyway).

SuSE (using factory Kernel module)

By default, coda does not load during startup, so here’s how we get it loaded at boot:

    yast2 sysconfig -> System -> Kernel -> MODULES_LOADED_ON_BOOT

Add the module name “coda” without quotes. If you already have other modules listed use spaces for delimiters. After boot, you can verify that it loaded with:

    # dmesg |grep coda
    coda: module not supported by Novell, setting U taint flag.
    Coda Kernel/Venus communications, v6.0.0,


    # lsmod |grep coda
    coda                   29892  0 

Installing and Configuring a Coda Server

This section deals with the installation and configuration of a Coda master server. This section needs many updates. The following list is far from exhaustive.


There are four phases of installing and configuring a Coda server.

  1. Set up the server system
  2. Obtain and install the server packages
  3. Configure and start the server
  4. Configure volumes for use

Once these steps are complete, the server is usable (if not particularly useful).

Setting Up a System for Use as a Coda Server

Unlike some other network file systems, Coda requires some thought be put into the actual server system configuration. Beyond the usual considerations of memory, network capabilities, processor speed, it is important to make sure you have a solid partition and disk scheme in place before beginning.

Coda has three main directories/files that need consideration.

Recoverable Virtual Memory

Unlike older versions of Coda, the RVM log and RVM data no longer need to be on seperate partitions. In fact, it is preferable to use files.

If you decide to store this data in files, rather than on their own partition(s), you do not need any extra configuration at this point.

If you decide to store this data in a partition, you will need a partition formatted with the ext2 or ext3 filesystems. Reiserfs used to cause problems earlier [1]. This partition should be large enough to match the sizes specified when you configure the server. Before creating any partitions, read up on configuring the server so you know how much space to reserve.

Vice Server Files

Coda stores information about the server in the /vice directory under UNIX systems. This information does not take up much space, and does not need its own partition, except to keep it seperate from the operating system, if you wish to do so. If you decide this is necessary, the partition need not be large.

Volume Data

You will need a partition(s) or disk(s) on which the actual volume will reside. This partition can be any size you wish, and merely needs to large enough to hold all the data you plan on storing. On Linux the partition can be formatted with “ext2, ext3, reiserfs, ramfs, tmpfs, probably even jffs2” On BSD “ufs will work just fine” [ibid.].

The traditional mount location for volumes is /vicepa, /vicepb, /vicepc… (meaning Vice partition A, Vice partition B…), but any mount point could be used. Nothing needs to be done to this partition as of yet. It will be configured for use with Coda when configuring the server itself.

Obtaining and Installing Coda

Coda can be installed from pre-built packages or from source. The latest releases can be found on the Downloads page.


The traditional UNIX build methodology works to compile and install Coda under Linux. Alternatively, packages have been rolled for some distributions.

Compiling from source

If you have troubles with any other method of installation, fall back to this one. It should work on any *nix platform provided you have the proper development environment installed.

The following illustration was performed on a GNU/Linux system:

Prerequisites: Ensure that you have the following installed prior to compiling as they are required:

What to do:

  1. Download the source:

    First of all, we need to get the latest (6.0.14 at the time of this writing) source tarballs from one of the coda mirrors

     cd /usr/src
  2. Unpack the tarballs:

     tar zxf coda-6.1.2.tar.gz
     tar zxf lwp-2.3.tar.gz
     tar zxf rpc2-2.4.tar.gz
     tar zxf rvm-1.13.tar.gz
  3. Compile and install them in the following order:

     cd /usr/src/lwp-2.3
     make install
     cd /usr/src/rpc2-2.4
     make install
     cd /usr/src/rvm-1.13
     make install
     cd /usr/src/coda-6.1.2
     make server-install
Using RPM packages directly

After downloading the packages, do:

    rpm -Uvh lwp-version.i386.rpm
    rpm -Uvh rpc2-version.i386.rpm
    rpm -Uvh rvm-version.i386.rpm
    rpm -Uvh rvm-tools-version.i386.rpm
    rpm -Uvh coda-debug-server-version.i386.rpm
Fedora packages

Write me! For FC3 use the FC2 RPMs. They work.

Gentoo packages

A simple emerge should be enough to install the coda client, server and required dependencies. Note: if you have the ‘kerberos’ USE variable set you will build a coda client with kerberos as the default authentication mechanism. note kerberos support without modular clog is broken.

     emerge coda

The official coda ebuild only supports 32-bit. The 64-bit version os in the way, read here:

Debian packages

Use the coda repositories on Add the following line to your /etc/apt/sources.list, replacing stable with testing or unstable if appropriate:

    deb stable/

Then do

    aptitude update
    aptitude install coda-server
SuSE packages

There are no maintained SuSE packages available, you will need to compile from source.


Write me!


Write me!

Configuring Coda

Configuring Coda is relatively simple, thanks to a provided setup script that (hopefully) will do all the work for us. However, undoing a Coda installation is somewhat difficult, and so you want to get it right the first time. If you mess something up, your best bet is to uninstall Coda (if you used RPM’s, DEB’s, portage, or some other package management system), remove all the created directories and files (including the configuration files in /etc/coda/) and start over.

Before starting, there is an issue you may wish to resolve. If you do not have (or are not using) a DNS server (ie, you want to access your Coda server by IP address only) you may have to edit /etc/hosts and remove any extraneous binds that connect your server’s hostname to the loopback IP address (127.?.?.?). If you do not, Coda may get confused and configure itself as if the loopback is a valid device to connect to, which of course creates problems. Read more on thise Configure_Coda_without_DNS.

When you are ready to configure the server, do:


An interactive script will run, which will prompt you for information as it configures the server. The following is a walkthrough of the various prompts you need to answer.

Configuring a Coda Server (2002/10) - Runs through a Coda 5.3.19-1 vice-setup (hardly relevant???).

Write me!

Configuring Volumes for Use

So now our server is configured and running. Until we configure a volume for access, however, it can’t actually do anything, and clients cannot connect. Because we told vice-setup about our volume in the previous section, all that is necessary now is to prepare it for use. Note that this is a one time operation. This does not need to be repeated after this time.

To configure the root volume, simply run the command as shown in the final output of vice-setup. For example, you might do the following:

    createvol_rep /

Make sure you execute the command specified in the final output of vice-setup exactly, even if it disagrees with other sources of information. vice-setup knows best!

Installing and Configuring a Coda Client

To be written. Depends on the OS in question.

Running Coda

System Administration: Volumes

System Administration: Users

There are two systems in place for managing users on a Coda server: pdbtool and au. pdbtool is provided with the server software, and is used to create and manage users and groups on a broad scale. au is provided with the client software and is used to perform modifications to accounts (usually remotely, though if the client software is installed on the server it could be run from there as well).

A typical situation might consist of the owner setting up some number of users and groups via pdbtool and then informing users to change their passwords via au.

General User Information

Like in a typical UNIX environment, users authorized for access on a Coda server are designated with a name, a user id (uid), and a group id (gid). Groups hold some number of users, and allow for grouping users for common file permissions.

It is very important to keep in mind that uids and gids (and names) have no bearing on actual users on the clients or server. They are constructs of Coda, and exist only within that frame of reference.

No longer valid (?) (and totally irrelevant) : You may not create a user or group with an id of 0. Beyond that, there are no real restrictions (beyond the typical naming regulations) on user creation.

Using pdbtool

pdbtool runs as an interactive shell on the server.

    # pdbtool

Commands are entered at the prompt, along with any arguments.

    pdbtool> help

The “help” command displays a listing of all the available commands. Administrative actions can be performed using these commands, as shown here. Note that this list is not exhaustive.

Managing Users

Important note: new users are created without any password (they can not authenticate until they also get a record in the Coda password database, see au).

    [Create a user with the username "nate".]
    pdbtool> nu nate

    [Create a user, this time specifying the uid manually, **don't**]
    pdbtool> nu molly 678

    [Delete a user]
    pdbtool> d bob

    [Get info on a particular user, either by name or by uid]
    pdbtool> i nate
    pdbtool> i 678

    [Change "nate"s uid and "molly"s name]
    pdbtool> ci nate 654
    pdbtool> cn 678 mollywolly

    [Clone "nate". Note that you are cloning a uid, and providing the copy with a new name.]
    pdbtool> cu nate_clone 654

    [Delete "mollywolly"]
    pdbtool> d mollywolly

    [Add "nate" to the "awesome" group. Either argument could be replaced with its id.]
    pdbtool> ag awesome nate

    [Remove "nate" from the group. The above id comment applies here as well.]
    pdbtool> rg awesome nate

Advanced Use of pdbtool

pdbtool has several advanced features for easing larger scale user management.

    [Execute a pre-written set of pdbtool commands.]
    source /home/nate/my_commands

    [The user database can be exported and imported for saving and restoring.
     User and group info are stored in seperate files.]
    export /home/nate/my_coda_users /home/nate/my_coda_groups
    import /home/nate/my_other_coda_users /home/nate/my_other_coda_groups

Using au

au manipulates coda user password records.

au runs as a command line program on a client. It can be run on the server, if it is configured as a client as well.


au has two phases of operation. First, you connect and authorize with the Coda server. Second, the chosen operation is executed. The first phase can only fail if you fail to provide a valid name and password to the server. The second phase can fail if the provided information for the chosen operation does not make sense, or if you do not have sufficient permissions to execute the command as attempted.

au should only really be used to make minor adjustments to the user system. For instance, new users would need to set their passwords. Or a server administrator might wish to modify an account on the fly, without connecting to the server directly.

Managing Users

    [Create a new account.  This can only be executed by administrators.]
    au -h MY_CODA_SERVER nu
    Your Vice name: MY_ACCOUNT_NAME
    Your password: MY_PASSWORD
    Vice user: NEW_USER_NAME
    New password: NEW_PASSWORD [Note: this echos in cleartext!]
    New info: NEW_INFO_STRING

    [Change a user's password.  This can only be applied to yourself, unless you are an
    au -h MY_CODA_SERVER cp
    Your Vice name: MY_ACCOUNT_NAME
    Your password: MY_PASSWORD
    User name: TARGET_USER_NAME
    New password: NEW_PASSWORD [Note: this echos in cleartext!]

    [Change a user's information.  This can only be executed by administrators.]
    au -h MY_CODA_SERVER cu
    Your Vice name: MY_ACCOUNT_NAME
    Your password: MY_PASSWORD
    Vice user: TARGET_USER_NAME
    New password: NEW_PASSWORD [Note: this echos in cleartext!]
    New info: NEW_INFO_STRING

    [Delete a user.  This can only be executed by administrators.]
    au -h MY_CODA_SERVER du
    Your Vice name: MY_ACCOUNT_NAME
    Your password: MY_PASSWORD
    Vice user to delete: TARGET_USER_NAME

The Backup System

Reinitializing Coda Servers after a Disaster

Coda Source Layout

Quick Reference

System Files

Common Problems and Suggestions

Example Configuration Files

Unix Man Pages

Coda Homepage

At its former host this page has been accessed 13201 times.

Last modified: Thu Jun 26 07:37:02 UTC 2014