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.
Kim
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.
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
