Re: Xsan 2 upgrade aftermarth issues

On Nov 24, 2008, at 9:57 AM, Vilius Šumskas wrote:

> Sveiki,
>
> Monday, November 24, 2008, 7:50:27 PM, you wrote:
>
> > On Nov 24, 2008, at 9:22 AM, Vilius Šumskas wrote:
>
> > > I have solved all problems except for #3. Can someone from Apple
> > > comment on
> > > this?
> > >
> > > I already have found that ACLs are indeed corrupted on the volume.  
> > > The
> > > question is: how do I fix them without rebuilding whole volume?
>
> > What indicates that ACLs are still corrupted?
>
> > Xsan 2.1 and 2.1.1 has a cvfsck that will verify all the ACLs in use
> > in the system and delete ones that are invalid. It will also scan all
> > files in the system to ensure they do not reference invalid ACLs. So
> > you should have no invalid ACLs after a successful check (and fix).
>
> > Note: cvfsck only verifies the integrity of the ACLs, it does not
> > check the SIDs in them with your directory service. So you could have
> > ACLs that reference non-existent SIDs. However these should not  
> > impact
> > file system stability (they should crash neither the fsm nor any
> > client) and should be correctable.
>
> > It sounds like you are encountering a different stability issue.
>
> Running "find /Volumes -user anyuser" always throws such errors:
>
> find: /Volumes/EditSAN/Laidos/matonis/Sluckis/Capture
> Scratch/0929_Sluckis/44 didele 12.mov: No such file or directory
> find: /Volumes/EditSAN/Laidos/matonis/Sluckis/Capture
> Scratch/0929_Sluckis/47 didele 18.mov: No such file or directory
>
> This  happened  before on Xsan 1.4.2. And was solved by recreating the
> volume  completely.  After  a  couple  of months these errors appeared
> again.  This  time  we  upgraded  to  2.1.1  and  ran cvfsck. It fixed
> something, but the errors still remains.

Double check the ACLs of the files along those paths, especially  / 
Volumes/EditSAN/Laidos/matonis/Sluckis/Capture Scratch/0929_Sluckis/ .

Xsan 2.1 and 2.1.1 resolved issues that led to ACL corruption and to  
volume (fsm) and client instability (crashing) as a result. It is  
still possible to create ACLs that prevent users from accessing files.

Note also that it is possible to craft permissions on a directory that  
let users see the presence of files yet not be able to access them.  
POSIX permissions of "r--" on 0929_Sluckus for the user running the  
"find" command would let a user "list" the directory yet not "search"  
it.

While this obviously isn't the behavior you want, things don't yet  
indicate an error with Xsan.

Take care,

Bill _______________________________________________
Do not post admin requests to the list. They will be ignored.
Xsan-Users mailing list      ([EMAIL PROTECTED])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/xsan-users/alexiscircle%40gmail.com

This email sent to [EMAIL PROTECTED]