Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

Environment: SharePoint 2010 Enterprise, Windows 7 Pro, ~200 users, I am the sole administrator and have full access to every aspect of the server/sites.

The short version:

The "open with explorer" feature works on every library in a site collection except one library where inheritence was broken, even though the permissions for most user groups are identicle to the other libraries where it DOES work.

The full version, with the troubleshooting steps I have tried:

Until recently, the "Open with Explorer" feature has been enabled in all libraries for most user groups. Just recently I was forced to break inheritance on one of those libraries to implement fine grained permissions. However, since breaking inheritence NO users can open with explorer at any level of the library, regardless of their permissions. They can still use this feature on other libraries.

After researching this I have eliminated/confirmed several things: -The users have the proper permissions on the library -Browser compatability is not the issue -All the proper Windows features are enabled -The problem exists regardless of browser or operating system -The problem is consistent across every account and computer

The fact that it is so consistent makes me think there is a single simple cause. The first thing that comes to mind (and by far the worst possibility) is that the open with explorer function is simply diabled for an entire library when inheritence is broken. I shudder to think of that being the case because it would muck up the whole security setup. If so, is there possibly a work-around or third party tool to restore the function AND keep the security the way it is? I can change site code if necessary but would rather avoid that.

As always, any help is greatly appreciated! Thanks!

UPDATES: To clarify, the "Open with Explorer" control is greyed out and says "This control is currently disabled" when you mouseover it. This is true for all users regardless of their permissions. It is possible to open a different library in Explorer and then navigate to the one in question using Explorer. I also managed to map a network location to the library with no trouble, so it appears that the control itself is the only issue. All permissions are in place for it to work for administrative and member accounts, but it still is not available to anyone.


Further updates: I have tried removing and re-adding (to library permissions) a test user and a test group that already existed in SharePoint, and then tried creating a new user and a new group and adding them. All of the mentioned accounts had Full Control. None of them were able to use the Explorer control.

Alternatives? Thinking outside the box: Is there another way to alter permissions? Would PowerShell produce different results or give different functionality? Could site/collection features somehow be interfering (I've seen odd behavior from some things like the Publishing features)? Is there a process to basically detach and reattach the library to the site to reset everything (similar to how you can de/reattach a content DB to clean up orphaned sites)?

share|improve this question
1  
Try opening another library in Windows Explorer, and then navigate to the library in question. Can you see it? –  David Lozzi Nov 20 '12 at 20:52
    
I am unable to reproduce this bug. What do you mean saying "No user can open with explorer". Does this mean the ribbon button is grayed, or just explorer fails? –  ppatalong Nov 20 '12 at 20:52
    
@ppatalong To clarify, the button is greyed out and marked with the generic "This control is currently disabled" mouseover dialog. This is true for all users regardless of their permissions or group. –  thanby Nov 20 '12 at 21:50
    
@David Very clever idea, it actually is possible to do that. I even created test documents inside the library in question after navigating to it in this fashion. It appears the control itself is the problem. –  thanby Nov 20 '12 at 21:52
    
Also @ppatalong I tried reproducing this on another library by breaking inheritance and changing permissions of a sub-directory, but despite that it still worked properly (as in, I was still able to use the "Open with Explorer" control on the test library) –  thanby Nov 20 '12 at 22:06
show 3 more comments

2 Answers 2

If the security change happened to include creating a new permission level or customizing an existing one then you will want to make sure that the "Use Remote Interfaces" and "Use Client Integration Features" options are enabled on that permission level

share|improve this answer
    
The security change was only for specific sub-directories deep within the library, permissions for the rest of it have not changed despite inheritance being broken. I have re-checked all permission levels to confirm this. With the exception of this one control, everything behaves as it should. –  thanby Nov 20 '12 at 22:03
add comment
up vote 0 down vote accepted

After a lot of digging around and asking other administrators, the only answer I can get is just "It's broken, abandon it." This is unfortunate but I was looking for an excuse to restructure this particular library anyway, because it's growing so fast that it really should be split up into multiple libraries just because of the sheer volume of data it contains (it went from 4GB to 25GB in about three weeks!).

Thanks to Dave Wise and ppatalong for their contributions, and thanks to David Lozzi for suggesting a clever work-around. For anyone who didn't see, the work-around was to map a network location to the library, or to open another library in Explorer and then navigate to the one in question.

If i come up with any other solutions I'll post them here.

Cheers!

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.