1

I'm having a problem with a WSS 3.0 instance where users keep losing their upload access rights every night.

Users can always enter the Site involved and can browse lists, document libraries etc. just like normal, but they get an error when trying to upload documents, getting access denied error. This can be fixed by applying their access rights again in WSS, but it has to be done every morning, making that solution not feasible.

This is a dedicated virtual server and no other applications running on it.

Has anyone had a similar problem regarding WSS and Sharepoint access rights ?

Improve this question

2 Answers 2

Reset to default
1

I've only seen this happen when there is custom code accessing SharePoint and is removing the users. Check the server logs in inetpub to see if a person or service account is actidentally removing people.

WSS will not just remove people at random, it has to be told to do so.

Also check your timer jobs in the Central Admin.

If you are talking about a few number of users, I can provide you with a PowerShell script that will give their upload rights to them on a schedule.

Improve this answer
2
  • I looked at the event viewer, sharepoint logs and our custom logs (via log4net) but no visible errors. Users get 403 forbidden after the IIS has been reset, I'm thinking this might be an IIS authentication error of some sort. If you could give me that PowerShell script that would be great :)
    – armannvg
    Jun 6, 2010 at 18:08
  • 1
    Issue solved with reinstall. However I'll mark your answer as correct for your troubles :)
    – armannvg
    Jun 16, 2010 at 3:21
0

I have seen similar symptoms of this in cases where an Active Directory user account has had some change to it. Where the change affected the security ID of the user account. Then in SharePoint the previous sid is stored in the profile service.

The symptom usually becomes apparent when the user accesses SharePoint after being away for a while, they are able to do what they need to do. Until they look at a document in OWA. Then at that time when a SID mismatch is noted, the system ripps the users access.

I have resolved this issue by completely deleting the affected user from the profile service and any sites they are in. Then re-adding them.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .