Common error messages

of Kiss Coda Wiki


Command-line errors

cannot bind to rpc2portmap; exiting (update server won’t start)

updatesrv won’t start and /vice/srv/UpdateSrvLog says cannot bind to rpc2portmap.

Most likely your /etc/hosts file is not properly setup to refer localhost lookups to the loopback interface. Make sure you have a line like this:               localhost localhost.localdomain

See this thread for details:

Cannot mount /vicepa partition

Contrary to the ancient documentation, you may fsck a coda partition if that partition is anything other than a “raw” partition, such as ext2 or ext3.

Log Messages

SFS:No Inode summary for volume 0x1000009; skipping full salvage

SalvageFileSys: Therefore only resetting inUse flag

Says Jan in this message

This should be normal for any volume without files, we have a bunch of these when servers are started.


Initialization errors

LogInit/RVM alloc failed

This is likely if the directories /usr/coda/etc or /usr/local/coda/etc do not exist. If these are created, then the likely problem is that the incorrect user has permissions to create log files within them. In cygwin, the Windows user SYSTEM runs all services and requires r/w permissions on all log files. In linux, this user would be root. The following commands fix the problem in cygwin:

    [user@host ~]$ chmod -R 664 /usr/coda
    [user@host ~]$ chown -R SYSTEM /usr/coda

In Windows, changing the “venus” service to start automatically and rebooting Windows will correctly load Venus.

Behavior errors

find command doesn’t traverse volumes

If you are in your root realm directory and the only subdirectories are volumes and you run “find .” the find command will not traverse down into the subdirectories. To get find to drill down into volumes, use the -noleaf option, like this:

    find . -noleaf

The noleaf workaround is no longer necessary as of Coda-6.0.9. It disabled an optimization in find, where it takes the directory linkcount, subtracts 2 (‘.’ and ‘..’ entries) and then subtracts one for each subdirectory it encounters. Once the counter hit zero it assumes everything else will be a file and as such doesn’t call stat(2) on the remaining directory entries. This optimization was broken for Coda as our volume mountpoints are represented by ‘magic’ symlinks and do not add to the directory linkcount. However for applications they are still visible as a subdirectory. We now return a linkcount of 1 for directories, find then subtracts 2 and ends up at -1. This way it will not hit zero and will end up calling stat(2) on every directory entry. –Jan Harkes 17:26, 9 Jun 2005 (CEST)

Conflict Repair Errors

You still need a dorepair because the Version state is different

VIOC_REPAIR /coda/realm/conflict/path: Resource temporarily unavailable

Repair failed.

This may be due to a version mismatch between the server and the cached replica objects. Try flushing the cached replica objects by following these steps:

    cfs br /coda/realm/conflict/path            # expand the conflict
    cfs getfid /coda/realm/conflict/path/*      # show version vectors
    cfs fl /coda/realm/conflict/path/*          # flush cached replicas
    cfs getfid /coda/realm/conflict/path/*      # refetch and show vvs
    cfs er /coda/realm/conflict/path            # collapse the conflict

If the version vectors changed, then you should try the repair process again.

Too few directory entries; Could not allocate replica list; beginrepair failed

If running the repair command results in this:

    # repair
    repair > beginrepair filename
    Too few directory entries
    Could not allocate replica list
    beginrepair failed.

And running

    cfs beginrepair filename

results in a global file that is a broken link, you probably have “a combination of a server-server (resolution) conflict and a local-global (reintegration) conflict.”

Jan Harkes explained the problem and the solution to the mailing list

cfs purgeml should get rid of the local-global (reintegration) conflict.

At this point you would only have the server-server conflict left, if this is a file it can be completely removed with

    removeinc passwd_manage

or repaired with,

    cfs beginrepair passwd_manage
    cp passwd_manage/some_replica /tmp/passwd_manage.recovered
    cfs endrepair passwd_manage
    filerepair passwd_manage /tmp/passwd_manage.recovered

Command-line errors

My data disappeared and now there’s a broken symlink

There has been a conflict. See the Dealing with conflicts page.

ls: permission denied

This can be caused by a lot of things. Check ctokens to see if you are authenticated, then check cfs la . to see if the user you’re logged in as has rights to read the current directory (or whatever directory you can’t read). If the cfs la command returns Connection timed out, then it is likely that you or that volume are disconnected due to a network problem or a conflict. Type

    cfs lv /path/to/directory

and look at the results. It will tell you if you are write-disconnected and if there are conflicts.

Log Messages

CacheFile::ValidContainer: 00/00/00/2B invalid

Found in venus.log.

From an e-mail to the coda mailing list by Jan Harkes: This was probably an open-for-write file, during recovery the size doesn’t match the recorded size in RVM. We only get to see the new size when the file is closed.

Local inconsistent object at ???/blah/blah, please check

Found in the console log file. This means that prior to mounting a volume was found to have a conflict and is not being mounted. The ??? indicates that the mount point is not yet known for this volume.

worker::main got bogus opcode 35

Harmless error message, it will be either opcode 35 or opcode 36. The kernel simply checks if the Coda client is capable of handling the CODA_STORE/CODA_RELEASE upcalls. If the client returns an error the kernel will fall back to CODA_CLOSE. The only problem is that at the time CODA_CLOSE is sent, we can no longer propagate errors back to the application. However most applications don’t even check for errors on close(2), so this is really not such a big problem.

Venus already takes the safe route and assumes nobody bothers to check for close(2) errors. When we fail while writing data back to the servers it will switch the volume to write-disconnected (or even disconnected) mode and commit the store operation locally in the modification log. When the following reintegration fails we mark the object as a conflict. –Jan Harkes 17:34, 9 Jun 2005 (CEST)

VLDBLookup: No or bad vldb.

You’ve forgotten to make a root volume: Quick_Server_Action

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

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