On Jul 27, 2010, at 12:52 PM, Dan Shoop wrote:
> > On Jul 27, 2010, at 2:49 PM, Chris Murphy wrote: > >> On Jul 27, 2010, at 12:26 PM, Dan Shoop wrote: >> >>> >>> On Jul 27, 2010, at 12:13 PM, Chris Murphy wrote: >>> >>>> >>>> On Jul 27, 2010, at 9:32 AM, Dan Shoop wrote: >>>>> >>>>> The latter is not a supported operation. Yes, I know that sounds crazy >>>>> but that's not a workflow Adobe approves of with their products Instead >>>>> save locally, then copy. Directly saving files in Adobe products to >>>>> fileshares has never been supported by Adobe. >>>> >>>> Understood but it has worked flawlessly from InDesign for a year with >>>> POSIX permissions. Upon changing to ACLs, we get a permissions error from >>>> InDesign. Today we removed the ACLs, and went back to conventional >>>> permissions and now InDesign can write directly into these drop folders. >>> >>> Which only indicates that you did not properly capture the required set of >>> ACEs. Anything you can do with ownerships and permissions you can achieve >>> better with ACLs. >> >> Seems like a reasonable explanation. >> >> Admins on the other end are telling me that during the test phase the ACLs >> were working correctly for all users and all drop folders. And then >> inexplicably a week into deployment users started getting the permissions >> error from InDesign. > > So something may have changed. *shrug* Not intentionally! i.e. at least no one is fessing up to having modified the shares' ACLs between the time it was working and the time it wasn't working; and also the ACLs as reported by ls -le are the same when it was working and when it wasn't working. But heck with marginal drives it may not be the ACLs that are corrupting, but something else related to either the interpretation of them. > >> And this approximately coincides with the XServe announcing a SMART failure >> prediction for one of the mirrored drives. So for all I know, iffy drives >> are corrupting themselves and it's just coincidentally making ACLs look like >> the problem. > > > Entirely possible. Google for "Silent Data Corruption". Wow. That's kinda shocking. I mean, it shouldn't be, but it's almost like we're f'd with a basic backup plan because the odds of having simultaneous corruption of a critical file over the course of time on two separate drives is actually not insignificant. > > And this isn't a RAID5, is it? If so, you're in for problems. It is RAID 1. So, yes. It's a relatively low priority server, in that it's not accumulating critical data. We can blow it away, rebuild it, and restore the print queues very quickly and be back up and running - even if we had to change platforms since it's a 3-platform RIP. However, the lack of error detection means the software RAID 1 likely took corruption as valid changes and propagated that to the other drive. So there's a good chance the data on both drives is f'd. That's the take away from this....rebuild it all from scratch, not from backup and not allowing the new drive to be rebuilt from the mirrored drive. Chris_______________________________________________ MacOSX-admin mailing list [email protected] http://www.omnigroup.com/mailman/listinfo/macosx-admin
