nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Intermittent Permissions Error

NotApplicable

Running: We are using Windows 2000, Teamsite 5.5.2, NT 4 Domain. User's have correct permissions in all UID files, submit.cfg, and "Y" drive. Permissions fail intermittently, within seconds of trying. We have rebooted the domain controller per Knowledge Base Article#2185, which worked once for a period of 2.5 weeks and has failed to work therafter. Specifically, once an editor checks a file and clicks the 'Edit' button they receive this error:

"Teamsite: FileEdit Error: You cannot edit the file since you do not have permission to modify the workarea."
KPirrong@BCIdaho.com

Thank You.

Find more posts tagged with

Comments

jmcdonald

Permissions have been eating our lunch as well...we're running Windows 2000, Teamsite 6.1. I expect it's some combination of lack of experience on our part and some arcane hocus-pocus going on in the bowels of Teamsite. IWCHGROUP in particular has caused us serious aggravation, when we need to change the "group for sharing" owner. We've been using SUBMIT.CFG with some success to reset file permissions, but you'd think this shouldn't be necessary.

Just the other day I had a file in a Workarea, for which I was the owner, and my ID (master) had full permissions on. I would "EDIT" the file, (download local) but then could not upload. Teamsite kept giving me an "error on upload" error message. The file was not locked by another user. Finally ended up creating a new file, copied the existing files contents over, and deleted.

My suggestion would be to try IWTESTCFG on the files/folders in question, maybe try iwreset -a after permission changes...good luck.

NotApplicable

Actually, our problem is exactly like the problem described in Interwoven's Knowledge Base Article #2185; however, the solution recommended in that article only worked on a one time basis for us.

We use submit.cfg to assign staging area permissions for group access to work areas and to secure specified content in Staging. Running iwreset -a has been tried to no avail. We always run iwreset after changing permissions and if iwreset doesn't work, we run iwreset -a; however, that is not our problem. We have not "changed permissions". Permissions show as "full" on the "Y" drive, and are correct in submit.cfg. This is an "intermittent" problem, which I have personally witnessed by standing next to content contributors while it was happening. One second they can authenticate and the next second they can't, then a couple minutes (or hours later) they can again. NO changes have been made to affect their ability to authenticate. It has to be something within TeamSite or perhaps a hardware issue.

KPirrong@BCIdaho.com

Adam Stoller

It sounds like your TeamSite server and your account-server (either PDC in NT terms or ActiveDirectory server in W2K terms) aren't communicating very well - I'd suggest getting your network folks involved to watch packets going in between the two systems and see if they can detect a pattern for failure.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

NotApplicable

Thank You. That is a very good suggestion.

KPirrong@BCIdaho.com