We had a problem with this at the last place I worked -- turned out to
be the Linux clients getting an all-zero UUID on startup. When somebody
without permission with the same UUID would auth to the cell and start
doing file IO, our machines would quit being able to use IP-based ACLs.
I thought there was a fix in the 1.4 branch at some point, but we got
around it quickly by running fs uuid -generate on startup after the link
came up.
Kevin Sumner
ITS Enterprise Storage Management
University of North Carolina at Chapel Hill
CB# 1150, 440 W. Franklin Street, Office G408
Chapel Hill, NC 27599-1150
[email protected]
919.962.1547 (office)
919.259.9734 (mobile)
919.445.9485 (fax)
Jeff Blaine wrote:
We use IP-address-based ACLs on one of our Solaris 9 clients
with no problems.
This Linux box we're trying to set up the same way is having
none of it.
The admin work:
ADMIN% pts creategroup silkhosts
group silkhosts has id -1594
ADMIN% pts adduser X.Y.11.70 silkhosts
ADMIN% pts adduser X.Y.11.39 silkhosts
ADMIN% pwd
/afs/whee/project/silk
ADMIN% fs sa . silkhosts rlidwk
ADMIN%
The failure:
OpenAFS 1.4.7 client
Linux coll 2.6.18-92.el5 #1 SMP x86_64 x86_64 x86_64 GNU/Linux
~:coll> ifconfig -a | grep 129
inet addr:X.Y.11.39 Bcast:X.Y.11.255 Mask:255.255.254.0
~:coll>
~:coll> cd /afs/whee/project
~:coll> cd silk
-bash: cd: silk: Permission denied
~:coll>
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
