On Fri, 22 Dec 2006, Steve Devine wrote: > Derrick J Brashear wrote: > > On Fri, 22 Dec 2006, Steve Devine wrote: > > > >> We have had some odd behavior with some x86 clients (linux) > >> User will be unable to write, insert or delete in the root of their own > >> personal afs space. If they move up one directory they can write, > >> insert and delete ok. > >> So user sparty for instance can not write in: > >> /afs/msu/user/s/p/sparty > >> But he can write in > >> /afs/msu/user/s/p/sparty/web/ > >> This will not affect all users on the same box. > > > > What are the ACLs? > > ______________________ > system:administrators rlidwka > system:anyuser lk > sparty rlidwka >
I have noticed, that the unix file permissions will get in the way especially, overwriting files. like cp -p /etc/shadow to /afs/somewhere then repeat it. I have had to change the unix permissions on the files even with a root token to overwrite a file like from 444 to 544 with the 1.4.2 client on Solaris 10. It sounds more like flock support being pulled into the client code. *shrugs* It is a change from the older versions of the clients.. -------------------------------------- Sean O'Malley, Information Technologist Michigan State University ------------------------------------- _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
