Go into Central Admin and search of "Policy." You can create a policy to give
an account access  to all Site Collections whether it's given permission at the
Site Collection level or not.

Yes, you can technically remove  "All" rights from a web or site
collection completely, but you still have the "Site Collection
Administrators" group, as well as the site  Collection owner and Seondary
owner (Both of which are added to the Site Collection Administrators
group) that you can add yourself into if you are a Farm administrator
so that you can get access  back to it.

Go to Central Admin

Select the "Application Management" tab

Select "Site Collection Administrators"

Select the appropriate Site Collection.

There "Has" to be a primary owner set, so my guess is that what it is
currently set to is not the account your trying to access the web within
this site collection.

Once you've added yourself, or see the account that "Can" access the
site collection, then from the site itself:

"Site Actions"

"Site Collection Administrators"

Which will take you to where you can add more than the primary and
secondary owners.

Or you could always go to your favorite directory and mine (ala
%systemroot%\Program Files\common files\Microsoft Shared\web server
extensions\12\bin) and run stsadm -o siteowner and give yourself access  back
to the site  

Let's hear it for our trusty friend stsadm

I like using the stsadm command from %CommonProgramFiles%\Microsoft Shared\web
server
extensions\12\bin\

Being the command shell junky that I am (We don't need no stinkin' GUI), you'd
wonder why I didn't suggest that :) Oh well, I guess it's from all those years
of support and "Guiding" people through the proper click path in the SharePoint
UI.

Tell me you haven't given into the dark side of the GUI... please?

I focus on the back end infrastructure of DeliverPoint.

I leave the "Make it pretty" stuff to Todd while I focus on the aspects
that actually do something

My philosophy has always been, "If you design your code right, and it
has sufficient access  points...You can unit test from anywhere, and
throw whatever kind of User Interface you want on top of it."

In other words, make the code work...Then worry about the UI, but when
you work on the UI, yeah....You have to make it presentable...I leave
that to someone else

To most people, the GUI is the application. It doesn't matter how good
the backend works, it the GUI sucks, most people (are developers people)
will diss (http://urbandictionary.com/define.php?term=diss) the
application and may not use it at all.

Course, the most elegant front end cannot make up for a buggy back end.
Hand and glove... hand and glove.

I do agree with you that for most people, the GUI is the application.
That's what made the STSADM for Windows so popular. It didn't actually
do anything except construct a proper STSADM command line, then spawn
STSADM.

I can't count the number of requests I had from folks to do a GUI for
all my previous tools, but my response was generally "Hey, I'm not
getting' paid for this...I'd love to do a GUI for you, but well..." And
then someone put together a q uick wrapper using Windows
Forms that did the same thing that the STSADM Window wrapper did. It
lasted about a month, because I added like 5 new commands to
SPSiteManager, and the guy could not keep up.

Regardless, yes...the GUI has to be presentable and usable or people
will not use it.

Now, I did do GUI work back in my Delphi days (There's a bit of my
history there for you) but strangely, I would prototype something using
a RAD tool like Delphi, the code up the hard core processing stuff in
C/C++, then the GUI was a big, big STUB for all my back end stuff.

I'd say at this point, we've officially gone way off topic for this
thread and we should end it.

One more quick statement: I am recreating the StsAdmWin for v3. I've
been about 80% finished for months. Someone must really want it for me
to put it back on the priority list.