Loading...

xsan-users@lists.apple.com

[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: Xsan 2 upgrade aftermarth issues William Stouder-Studenmund Mon Nov 24 11:00:50 2008

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]