[OpenAFS] Read-only volume issues

[Garrison, Christine]

Hi Jeff,=0A=
=0A=
Does "vos addsite" duplicate a volume's data? Because we are using much mor=
e than half our capacity, and therefore can't afford to double usage. To be=
 blunt, we are trying to make the system read only by stages to encourage u=
sers to migrate off this system as we are trying to retire it at the end of=
 the year.=0A=
=0A=
If mounting the .backup volume isn't a good option, then that more or less =
leaves me with walking the filesystem, parsing and changing ACLs to have no=
 write/insert/delete. This would be irreversible unless I stored the origin=
al ACL states somehow and could re-apply them later if there was a mistake =
or a political reason to restore a volume to be writeable for awhile.=0A=
=0A=
Though, I am open to ideas. It seems awful to ask about how to retire an Op=
enAFS system on this list, however.=0A=
=0A=
> What are the errors?   Obviously, any access that expects write permissio=
n or the ability to obtain a lock is going to fail when the volume isn't wr=
itable.=0A=
=0A=
Well the errors indicate the files can't even be read, despite that not bei=
ng the case (at least, it works fine within OpenAFS and with the sftp and h=
ttp gateways we have sitting on top... just not Samba.=0A=
=0A=
OS X at least says:=0A=
=0A=
"The document =93Document.rtf=94 could not be opened."=0A=
=0A=
...and if I copy to the desktop, it says:=0A=
=0A=
"The Finder can=92t complete the operation because some data in =93Document=
.rtf=94 can=92t be read or written.=0A=
(Error code -36)"=0A=
=0A=
Chris=0A=
--=0A=
E. Christine Garrison=0A=
Indiana University=0A=
Research Technologies=0A=
Research Storage=0A=
=0A=
________________________________________=0A=
From: Jeffrey Altman <jaltman@auristor.com>=0A=
Sent: Monday, June 20, 2016 2:36 PM=0A=
To: Garrison, Christine; openafs-info@openafs.org=0A=
Subject: Re: [OpenAFS] Read-only volume issues=0A=
=0A=
On 6/20/2016 1:59 PM, Garrison, Christine wrote:=0A=
>=0A=
> I've been tasked with turning many volumes on our site read-only. What=0A=
> I've come up with is, I would like to unmount existing read-write=0A=
> volumes and mount their readonly .backup volume in their place.=0A=
=0A=
The .backup volume is considered transient and should not be relied upon=0A=
to exist.  To create a read-only volume use=0A=
=0A=
  vos addsite=0A=
=0A=
to create a replica site on the same service/partition on which the=0A=
normal RW volume exists.  Then execute "vos release" for each volume.=0A=
=0A=
The normal AFS mount points do not need to be altered.  When a cache=0A=
manager traverses a normal mount point, if there is a .readonly volume=0A=
instance that will be preferred over the normal RW instance.=0A=
=0A=
AFS clients cache the volume group information for a couple of hours=0A=
so you should not expect the .readonly to become visible immediately=0A=
on a client that has already accessed the normal RW instance.=0A=
=0A=
> The trouble comes in (as always) with our Samba service. We sit Samba on=
=0A=
> top of OpenAFS to serve our users, who have not wanted to install the=0A=
> OpenAFS client. It works as well as you might hope, but not for readonly=
=0A=
> volumes in OpenAFS -- if you map a drive in Windows or Mac OS X, you may=
=0A=
> browse the files, but any operation at all that involves reading fails=0A=
> with errors.=0A=
=0A=
What are the errors?   Obviously, any access that expects write=0A=
permission or the ability to obtain a lock is going to fail when the=0A=
volume isn't writable.=0A=
=0A=
Jeffrey Altman=0A=
=0A=