On Mon, Jan 22, 2001 at 02:17:30PM -0500, Brad Clements wrote:
...
> [bkc_at_eiger include]$ ls /coda
> ls: /coda: Permission denied

I suspect you might have removed all permissions for System:AnyUser from
the root directory of the root-volume.

In that case, clog is denied access to the `magic control file'
/coda/.CONTROL, which is needs to pass aquired tokens to venus.

> Fid 7f000000
> 
> But root volume is 1000001
> 
> Does that matter?

Ehh, did you create a replicated volume with createvol_rep? In that case
7f000000 sounds ok for the volumeid of the replicated volume, which is a
logical volume spanning one or more volume replicas. And 1000001 is the
one replica that stores the data for the 7f000000 volume.

Disconnected operation is only supported when using replicated volumes,
so it is always a good choice to never create non-replicated volumes,
and instead just create singly replicated volumes.

> I've turned on more tracing, and get this in /var/log/messages
> 
> Jan 22 14:09:26 eiger kernel: (do_time_stats,l. 141): time: 0
> Jan 22 14:09:26 eiger kernel: (do_time_stats,l. 141): time: 0

It is probably not a kernel problem.

> SrvLog
> 
> (something looks fishy here)

What? it looks fine.

> 09:29:33 VAttachVolumeById: vol 1000001 (root.0) attached and online

This is an underlying replica, and it is attached (exported). The client
seems to mount it fine, so it should be an ACL problem.

    Did you happen to do a `cfs sa /coda System:AnyUser none'?

    Which version of the coda client and server are you using.

    Which kernel version are you running? (even though I don't think it
    is kernel related)


Jan