Logo 
Search:

Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds

All Permissions GONE on a Site Collection

  Asked By: Tarang    Date: Sep 14    Category: Sharepoint    Views: 5305

First-Although this may seem impossible and a joke, It is no joke!
Luckly we have daily backups that work!

3 easy steps to break our SharePoint!
Step 1 - Create document library, the permissions do not inherit by
default (Main Problem, not sure why it does this).
Step 2 - Inherit permissions
Step 3 - Remove and reassign permissions

Result, Nobody can access our SharePoint, not even System Admin.

I do know that step 1 does not break our SharePoint environment. I
believe it has to do with step 2. Has anybody ran across something
similar to this and how to fix it. This has happen twice in less than
a week. The first time it happened we were unsure of the cause.

Share: 

 

10 Answers Found

 
Answer #1    Answered By: Katelynn Donovan     Answered On: Sep 14

You have something much deeper wrong with your system if Step 1 is
taking place. When document libraries are created they are always set
to inherit permissions. Unlike a Web site  there isn't even a switch in
the user interface to tell them to start with no permissions.

To fix it have you tried going into Central Administration and creating
a Policy for Web Application that gives an Admin Full Control of
everything in the Web Application that contains the document library.
This admin should then be able to get in no matter what the local
permissions on the Library are set to.

 
Answer #2    Answered By: Geraldine Slater     Answered On: Sep 14

I just took another look at this and have another question. If you
re-Inherit permissions  in Step 2 how are you removing and re-assigning
permissions in Step 3? Unless inheritance is broken there is no
interface for changing permissions except at the parent level. There is
only Manage Permissions of Parent or Edit Permissions on the Action menu
of the document library. Selecting Edit Permissions will copy the
parent's permissions and break inheritance again. If you select Edit
Permissions and remove all permission entries, the Site Collection
Administrator can still access the Document Library to add the
permissions back in.

I just took another look at my test system and this is the way it works
on a clean install.

 
Answer #3    Answered By: Gail Richmond     Answered On: Sep 14

Thanks for the quick and prompt reply!!! You are completly correct, I
missed the step of the re-de-inheriting (or breaking inhertiance for
the second time) to manage the permissions. Because of the
volatility of the problem I have not tired to manage the them without
inheriting the permissions.

In regards to the previous relpy... I AGREE, We do have a problem and
a major one at that!

We have not tried the policy, we just restored to the previous
business day. Are first step is to store over a copy to our
development environment. Then we can break and restore all day to
track changes to SQL and the registry. I thought it was the document
library template was changed, it might be, but my reasoning for
believing it isn't. I created a template from a newly create doc
library and imported into our dev environment and it works as it
should.

I guess the solution is to attach documents to list items from now
on.

Any and ALL ideas are welcome.

 
Answer #4    Answered By: Ramona Solis     Answered On: Sep 14

I was doing some googling of my own on a seperate
issue and stumbled upon this blog post. It sounds
like there is a hotfix for the issue you're
experiencing. Take a look here:

www.sharepointblogs.com/.../known-shar\
epoint-issue-switching-from-inherited-to-custom-permissions.aspx

 
Answer #5    Answered By: Harvey Blankenship     Answered On: Sep 14

In my portal I changed some permissions  of a non-inheriting subsite of
the sitecollection and it went error 500 - internal error. Recycled the
application pool and the rest of the portal was still accessible, but
every visit to that specific subsite resulted in an internal error.
Most painful.

We restored a backup and installed SP1 soon after, hopefully not seeing
this error again.

 
Answer #6    Answered By: Xiomara Blanchard     Answered On: Sep 14

this is a known bug with a hotfix
available. See here for details

support.microsoft.com/default.aspx/kb/937038

 
Answer #7    Answered By: Rosemarie Cervantes     Answered On: Sep 14

We were all excited to apply SP1 as it contained the hotfix. We
double checked the add/remove to see if SP1 had been installed and
didn't see it listed. However, when we tried it this morning it
errored stating that SP1 had already been applied. Does any know how
to double check the build version or how you know if SP1 has really
been applied?

 
Answer #8    Answered By: Manan Kadu     Answered On: Sep 14

You can find the verison number information in Central Admin.
Operations > Servers in Farm. On the page is Farm information including
the Version of SharePoint. On my non-SP1 test box its 12.0.0.4518 MOSS
SP1 should be 12.0.0.6219. See Penny Coventry's post here for other
version numbers:

http://mindsharpblogs.com/penny/articles/481.aspx

 
Answer #9    Answered By: Tonia Franco     Answered On: Sep 14

Thanks for the quick how-to! Our findings is that our Production MOSS
server is on version 12.0.0.4518. To me this indicates that we do
not have SP1 installed. We tired to install it, but we get a message
that it is already installed. Any tips on how to proceed?

 
Answer #10    Answered By: Amareswar Karkera     Answered On: Sep 14

so glad I have this listserv. I had a team subsite that was put in place a
few months ago. Today I was told to break the permissions  from the parent,
when I did, ALL of the permissions were gone from the top level site  and all
of the other subsites that inherited permissions. Luckily I caught it right
away and as I was re-entering the ADG's into the appropriate local groups,
my phone started ringing, e-mailsd IM's started flowing in. Other subsites
where I initially broke the permissions upon creation were not affected.

But then I had to find the cause of the issue and ran across this thread.
'Course now everything involving SharePoint is now going to have to go
through Change Management--which is a good thing. Funny thing is, there were
only a handful of people affected across the company and it was literally
momentary for each of them as I entered in the heavier users of the
SharePoint first.

In any event, at least now I know why what happened happened. Thanks to the
posters who left links to the HotFix and the blogs. It is appreciated.

 
Didn't find what you were looking for? Find more on All Permissions GONE on a Site Collection Or get search suggestion and latest updates.




Tagged: