[OpenAFS] AFS always readonly?
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.