[OpenAFS] AFS always readonly?

Kim Kimball dhk@ccre.com
Tue, 23 Oct 2007 14:28:32 -0600

You can also remove the root.afs.readonly instances, do an "fs checkv," 
add the "dot path"  (fs mkm /afs/.<cellname> root.afs -rw) and then 
replicate root.afs again.  After that /afs/.<cellname> will give RW 
access to all volumes mounted below /afs/.<cellname> as long as they're 
not explicitly mounted as .readonly or .backup volumes.


Brandon S. Allbery KF8NH wrote:
> On Oct 18, 2007, at 15:26 , Tim OBrien wrote:
>> machine. However, from the other machine, I can't create a mountpoint 
>> in afs or
>> do much of anything, since it states that /afs is mounted read only. 
>> I used the
> Normally if a read only replica exists it will be mounted by 
> preference.  The usefulness of r/o replicas is in fact dependent on 
> /afs mounting read-only by default.
> Usually one creates an explicit read-write mountpoint for the cell 
> (/afs/.cell vs. /afs/cell) while the initial root.cell and root.afs 
> are still not replicated.  Once you have the latter, you can always 
> create a read-write mount for root.afs or other volumes.  (-dynroot 
> should do this automatically)
> If you have inadvertently created a cell without a forced r/w mount in 
> your root.afs, there are two ways to fix it:
> - create such r/w mount in some other cell that has an r/w mount and 
> knows how to reach yours (requires you to auth to *your* cell, so 
> crossrealm/cross-cell auth is not necessary, but you may need to 
> insure that using your cell's Kerberos tickets won't cripple your 
> access to the machine in the foreign realm/cell)
> - bring up a client with -dynroot, which should get you an automatic 
> r/w mountpoint, and fix the static mounts from there.
> (Several years back when a combination of a corrupted r/w site for 
> root.afs and a pair of inexperienced admins caused our /afs to 
> suddenly become quite empty, afs didn't have dynroot.  Luckily I had a 
> test cell running which knew how to reach the main one, so I was able 
> to repopulate root.afs remotely.  These days -dynroot is almost 
> certainly the best way to go for this.)
> As for the difference between the two machines:  you probably haven't 
> restarted the client on the first machine yet, so its initial 
> read-write mount of /afs is still intact.  You should probably use 
> that to make sure the /afs/.cell forced read-write mount of root.cell 
> is present, and rerelease.