Jeff, Thank you for the "vos addsite" idea and for clarifying. That does seem like a better option, assuming we can solve the Samba problem. The .readonly volume produced acts just like the .backup mount did, so we are stuck. Windows reports "failed with an error of 5" upon attempts to open files through Samba from the .readonly volume mount.
I was pretty sure the answer here would be something like that, but the Samba also people haven't been helpful about OpenAFS issues for a long time, so we are kind of on our own. Which is one of the reasons we are retiring this system. Chris -- E. Christine Garrison Indiana University Research Technologies Research Storage ________________________________________ From: Jeffrey Altman <[email protected]> Sent: Monday, June 20, 2016 4:20 PM To: Garrison, Christine; [email protected] Subject: Re: [OpenAFS] Read-only volume issues On 6/20/2016 4:10 PM, Garrison, Christine wrote: > Hi Jeff, > > Does "vos addsite" duplicate a volume's data? >From an implementation perspective a .readonly instance on the same partition as the RW volume is identical to a .backup. The difference is that the .readonly is stable and mount points behave the way you want them to and .backup volume instances are unstable. If you move the volume the .backup will be destroyed whereas the .readonly will remain. > Because we are using much more 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 users to migrate off this system as we are trying to retire it at the end of the year. I assumed that is what you were trying to do. > 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 original 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. > > Though, I am open to ideas. It seems awful to ask about how to retire an > OpenAFS system on this list, however. The approach I have suggested will do what you need. >> What are the errors? Obviously, any access that expects write permission >> or the ability to obtain a lock is going to fail when the volume isn't >> writable. > > Well the errors indicate the files can't even be read, despite that not being > the case (at least, it works fine within OpenAFS and with the sftp and http > gateways we have sitting on top... just not Samba. > > OS X at least says: > > "The document “Document.rtf” could not be opened." > > ...and if I copy to the desktop, it says: > > "The Finder can’t complete the operation because some data in “Document.rtf” > can’t be read or written. > (Error code -36)" You are looking in the wrong place for errors. You need to be looking at Samba. Jeffrey Altman _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
