[OpenAFS] Read-only volume issues

[Garrison, Christine]

Jeff,=0A=
=0A=
Thank you for the "vos addsite" idea and for clarifying. That does seem lik=
e a better option, assuming we can solve the Samba problem. The .readonly v=
olume produced acts just like the .backup mount did, so we are stuck. Windo=
ws reports "failed with an error of 5" upon attempts to open files through =
Samba from the .readonly volume mount.=0A=
=0A=
I was pretty sure the answer here would be something like that, but the Sam=
ba also people haven't been helpful about OpenAFS issues for a long time, s=
o we are kind of on our own. Which is one of the reasons we are retiring th=
is system.=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 4:20 PM=0A=
To: Garrison, Christine; openafs-info@openafs.org=0A=
Subject: Re: [OpenAFS] Read-only volume issues=0A=
=0A=
On 6/20/2016 4:10 PM, Garrison, Christine wrote:=0A=
> Hi Jeff,=0A=
>=0A=
> Does "vos addsite" duplicate a volume's data?=0A=
=0A=
>From an implementation perspective a .readonly instance on the same=0A=
partition as the RW volume is identical to a .backup.  The difference=0A=
is that the .readonly is stable and mount points behave the way you=0A=
want them to and .backup volume instances are unstable.=0A=
=0A=
If you move the volume the .backup will be destroyed whereas the=0A=
.readonly will remain.=0A=
=0A=
> Because we are using much more than half our capacity, and therefore can'=
t afford to double usage.=0A=
> To be blunt, we are trying to make the system read only by stages to=0A=
encourage users to migrate off this system as we are trying to retire it=0A=
at the end of the year.=0A=
=0A=
I assumed that is what you were trying to do.=0A=
=0A=
> If mounting the .backup volume isn't a good option, then that more or les=
s leaves me with walking the filesystem, parsing and changing ACLs to have =
no write/insert/delete.=0A=
> This would be irreversible unless I stored the original ACL states=0A=
somehow and could re-apply them later if there was a mistake or a=0A=
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 =
OpenAFS system on this list, however.=0A=
=0A=
The approach I have suggested will do what you need.=0A=
=0A=
>> What are the errors?   Obviously, any access that expects write permissi=
on or the ability to obtain a lock is going to fail when the volume isn't w=
ritable.=0A=
>=0A=
> Well the errors indicate the files can't even be read, despite that not b=
eing the case (at least, it works fine within OpenAFS and with the sftp and=
 http 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 =93Docume=
nt.rtf=94 can=92t be read or written.=0A=
> (Error code -36)"=0A=
=0A=
You are looking in the wrong place for errors.   You need to be looking=0A=
at Samba.=0A=
=0A=
Jeffrey Altman=0A=
=0A=
=0A=
=0A=