If you've followed the instructions in the previous section, your Coda client is now talking to your Coda server, and you should be able to list the /coda directory on the client ("ls /coda") and see any files that are located on the data partition that the server is exporting. If you see output like that in the following example, your client and server aren't talking correctly:

ls /coda
NOT_REALLY_CODA

In this case, you should check your logs (/var/log/messages, for system problems, and /vice/srv/SrvLog, for Coda-specific problems). Unfortunately, debugging every possible problem is outside the scope of this article, but Coda usually just works.

If you can list the /coda directory on your client and see no files, the natural thing to do is to want to create a file there and make sure that you can see it from any and all Coda clients that are communicating with your server. To do this, you must authenticate to Coda, which will give you the privileges that you need to actually create files in a standard Coda filesystem. The Coda filesystem exported by CMU for Coda testing is specially configured to enable anyone to read and write there, which--as you might hope--is not the default configuration of a Coda filesystem. The following shows an unauthenticated attempt to create a file in /coda:

ls /coda
cp linux-coda-5.0.0.tgz /coda
cp: cannot create regular file `/coda/linux-coda-5.0.0.tgz': Permission denied

A complete discussion of Coda authentication is outside the scope of this article. Coda provides the au command to create and manage Coda user accounts and administrative groups. This example will authenticate as the administrative Coda user that was created during the server installation procedure discussed in a previous section of this article.

Authenticating to Coda can be done manually using Coda's clog command. In production Coda environments, Coda authentication is typically incorporated into the standard system login process using PAM or by adding the clog command to a user's login script. The following example shows using the clog command to authenticate as the "codaroot" user, which is the Coda system administration account that was created in the previous section of this article:

clog codaroot
username: codaroot
Password: 
19:24:01 root acquiring Coda tokens!

After authenticating to Coda (known as "acquiring tokens" in Coda-speak), you should now be able to create a file in the distributed Coda filesystem, as in the following example.

cp linux-coda-5.0.0.tgz /coda

In this case, no news is good news--the file was correctly copied to the /coda partition, which is the client's mount point for the Coda partition that is being exported by your server.

Next: Hoarding Files for Disconnected Operation »