Hi there. Background: Vault v2.0.6, 20 repositories, 12 users.
I am trying to Obliterate files in a given repository. I am able to successfully run the Admin Tool, and look at all the tabs/repositories without any problem except the Obliterate tab.
On the Obliterate tab, selecting 3 of the 20 repositories from the Repository combobox results an error message dialog box:
1009: FailPermissionDenied
This message is consistent (for these 3 repositories), repeatable (occurs each and every time), and obviously problematic - how to obliterate files!?!?
I have searched on the forums and see nothing like this bug, although perhaps this is a bug that is now fixed in v3.0?
http://support.sourcegear.com/viewtopic ... siondenied
http://support.sourcegear.com/viewtopic ... siondenied
I have tried deleting the folder on my HD as well, to no avail:
C:\Documents and Settings\DACarr\Application Data\SourceGear\Vault_1\Admin\9C3B637B-E245-4CE3-B1CE-FFECC428D329
Please note that on my colleague's machine, he IS able to choose any repository on the Obliterate tab without any problem.
Any/all help appreciated - esp. official word if this is a known 2.0.6 bug.
Thanks,
Admin Tool: Unable to Obliterate as 'FailPermissionDenied'
Moderator: SourceGear
Admin Tool: Unable to Obliterate as 'FailPermissionDenied'
David Carr
Senior Systems Analyst
ESSA Technologies Ltd.
Senior Systems Analyst
ESSA Technologies Ltd.
Have you checked your permissions on those repositories? Even if one has Admin rights, a person can manage to remove their permissions to some repositories.
How are you logging into the Admin tool; as yourself (with Admin rights) or as Admin? Whichever one you are using, try the other.
Something may be out of sync with your cache, though it still sounds more like a permissions issue. Either way, you can always try clearing your client side cache and restarting Vault. Wherever you use the Admin tool, there should be an Admin folder in the cache. More information can be found here: http://support.sourcegear.com/viewtopic.php?t=6
How are you logging into the Admin tool; as yourself (with Admin rights) or as Admin? Whichever one you are using, try the other.
Something may be out of sync with your cache, though it still sounds more like a permissions issue. Either way, you can always try clearing your client side cache and restarting Vault. Wherever you use the Admin tool, there should be an Admin folder in the cache. More information can be found here: http://support.sourcegear.com/viewtopic.php?t=6
Obliterate, not deletion, different btw 2 machines
Sorry Beth...perhaps I am not understanding how to use the 'Admin Tool' properly, or I am not being clear.
It is my understanding there is only 1 user that is able to run the Admin Tool - namely the 'Admin' user. This is the user that both my colleague and I are using to run the program, or more importantly, running the 'Admin Tool' on his machine and logging in as 'Admin' works fine where it is possible to obliterate a file from any repository. Running the 'Admin Tool' on my machine and logging in as 'Admin', upon changing the combobox on the Obliterate tab to each of the 3 repositories (out of 20) results in the '1009: FailPermissionDenied' message.
So I am not referring to deletion, but rather obliteration.
Hope this helps.
It is my understanding there is only 1 user that is able to run the Admin Tool - namely the 'Admin' user. This is the user that both my colleague and I are using to run the program, or more importantly, running the 'Admin Tool' on his machine and logging in as 'Admin' works fine where it is possible to obliterate a file from any repository. Running the 'Admin Tool' on my machine and logging in as 'Admin', upon changing the combobox on the Obliterate tab to each of the 3 repositories (out of 20) results in the '1009: FailPermissionDenied' message.
So I am not referring to deletion, but rather obliteration.
Hope this helps.
David Carr
Senior Systems Analyst
ESSA Technologies Ltd.
Senior Systems Analyst
ESSA Technologies Ltd.
Deleting Admin cache does not help
PS: Deleting the cache for 1 of the 3 repositories where Obliterate fails, that is, deleting this folder:
[Indent]C:\Documents and Settings\DACarr\Application Data\SourceGear\Vault_1\Admin\20DD4BDC-75DA-4E8C-A903-B46F68D41333[\Indent]
Has no effect. Problem persists.
[Indent]C:\Documents and Settings\DACarr\Application Data\SourceGear\Vault_1\Admin\20DD4BDC-75DA-4E8C-A903-B46F68D41333[\Indent]
Has no effect. Problem persists.
Did you have Vault shut down before deleting the cache? You may need to reboot your computer if it thinks that those files are in use. You can also clear the server side cache by restarting IIS.
Have you checked your permissions?
Do you know what kinds of things are different with your computer versus your colleague's computer? If your colleague can and you can't, then a difference in either the computers or permissions is mostly likely the key here.
Have you checked your permissions?
Do you know what kinds of things are different with your computer versus your colleague's computer? If your colleague can and you can't, then a difference in either the computers or permissions is mostly likely the key here.
Hi Beth. Thx for the speedy replies.
Yes, both my Vault Client and the Vault Admin Tool was shut down before deleting the folder specified in my previous message. I tried this again this morning with the same result.
IIS/Server - I have not yet tried this option, as our server is live with other important applications running on it. Before considering restarting IIS, are there any other suggestions you will have me perform on the server [so these can be done at the same time]?
Permissions - What permissions are you referring to? I am logged in as 'Admin'. From my previous post - Is there any other user that can log in to the Admin Tool?
As for it working on my colleagues machine and not mine...yes, clearly there is difference somewhere. No...only supernatural powers would enable someone to know what is different between two PCs running Windows...if you know how, please let me know and we can make a fortune!
Yes, both my Vault Client and the Vault Admin Tool was shut down before deleting the folder specified in my previous message. I tried this again this morning with the same result.
IIS/Server - I have not yet tried this option, as our server is live with other important applications running on it. Before considering restarting IIS, are there any other suggestions you will have me perform on the server [so these can be done at the same time]?
Permissions - What permissions are you referring to? I am logged in as 'Admin'. From my previous post - Is there any other user that can log in to the Admin Tool?
As for it working on my colleagues machine and not mine...yes, clearly there is difference somewhere. No...only supernatural powers would enable someone to know what is different between two PCs running Windows...if you know how, please let me know and we can make a fortune!
What alternatives are left?
Beth (and others),
Ok, so the remaining avenue to pursue was to restart the server and IIS. This has now been done (better or worse...power went down for whole bldg for hours). But the problem still continues for same 3 of the 20 repositories: "1009: FailPermissionDenied".
To shed some more light on this, I never noticed the 'Groups' tab. So rather than using my 'DavidCarr' user, I was signing into the Admin Tool using the 'Admin' user. It is the 'Admin' user that has the above failure. If 'DavidCarr' is added to the Admin group, the 'DavidCarr' user can then select any of the repositories on the Obliterate tab (incl. those problematic 3) with no error.
Further, this is the exact behaviour as my colleague. My previous posts where I found out he didn't have a problem, was because his 'Don' user was a member of the Admin group, and he was using this to Obliterate. Using his computer with the 'Admin' user, he experiences the same problem for the 3 repositories.
So while no supernatural powers are required (as it seems our PCs are functioning the same), it does seem that the 'Admin' user is screwed up and the alternatives thus far (deleting client cache, restarting server) don't solve it.
Any other ideas?
David
Ok, so the remaining avenue to pursue was to restart the server and IIS. This has now been done (better or worse...power went down for whole bldg for hours). But the problem still continues for same 3 of the 20 repositories: "1009: FailPermissionDenied".
To shed some more light on this, I never noticed the 'Groups' tab. So rather than using my 'DavidCarr' user, I was signing into the Admin Tool using the 'Admin' user. It is the 'Admin' user that has the above failure. If 'DavidCarr' is added to the Admin group, the 'DavidCarr' user can then select any of the repositories on the Obliterate tab (incl. those problematic 3) with no error.
Further, this is the exact behaviour as my colleague. My previous posts where I found out he didn't have a problem, was because his 'Don' user was a member of the Admin group, and he was using this to Obliterate. Using his computer with the 'Admin' user, he experiences the same problem for the 3 repositories.
So while no supernatural powers are required (as it seems our PCs are functioning the same), it does seem that the 'Admin' user is screwed up and the alternatives thus far (deleting client cache, restarting server) don't solve it.
Any other ideas?
David
You mentioned trying it on 3 of the repositories. Does that mean you've checked out any of the others to see if it happens there? Is it only those 3?
When you were deleting the client-side cache previously, how did you ensure you had the folder that went to the right repository? Generally, I'd recommend grabbing the entire Admin folder in the cache on your client and deleting it. Would you be willing to try that?
While you are doing that, I am checking into other avenues with this.
When you were deleting the client-side cache previously, how did you ensure you had the folder that went to the right repository? Generally, I'd recommend grabbing the entire Admin folder in the cache on your client and deleting it. Would you be willing to try that?
While you are doing that, I am checking into other avenues with this.
Exhaustive investigation - repeatable problem persists
Thx for your persistence Beth.
I have done an exhaustive investigation, and it seems that the client files have nothing to do with this problem. Further, this problem now spans users - although for different repositories. The details follow...
1. Our Vault contains 20 repositories with, in the world of sw development, likely a small-medium number of files in each. Let's call these repositories {R1, R2, ...R20}.
2. Yes, every repository has been selected on the Obliterate tab. The same 3 repositories {R7, R17, R19} generate this error message when logged in using the 'Admin' user, on both my colleague's machine and mine using this same 'Admin' user.
3. From checking everything, interesting to note that with my 'DavidCarr' added to the Admin group and using 'DavidCarr' to log into the Admin Tool, this same 1009: FailPermissionDenied error also occurs for this user on repositories {R5, R8, R9, R16}.
4. Point #3 above is clearly not a good discovery. While a[n annoying] workaround to Obliterate can be achieved by signing in using different users, if there is a repository that cannot be obliterated across all users then there won't be a solution. At present, at least the union of the Rx set in #2 and #3 is empty.
5. Yes, I am certain I deleted the correct files because I checked the Cache_Repository file (opening this, one can see at the beginning what it corresponds to). In the event I made a mistake, I have deleted the whole folder and everything below:
C:\Documents and Settings\DACarr\Application Data\SourceGear\Vault_1\Admin
then repeated the repeated the above process (i.e. checking every single repository) for the 'Admin' user. Same result. Then deleted this off again and tested for the 'DavidCarr' user, same result.
6. There was no other connection to Vault, other than through the Admin Tool, during this process.
I have done an exhaustive investigation, and it seems that the client files have nothing to do with this problem. Further, this problem now spans users - although for different repositories. The details follow...
1. Our Vault contains 20 repositories with, in the world of sw development, likely a small-medium number of files in each. Let's call these repositories {R1, R2, ...R20}.
2. Yes, every repository has been selected on the Obliterate tab. The same 3 repositories {R7, R17, R19} generate this error message when logged in using the 'Admin' user, on both my colleague's machine and mine using this same 'Admin' user.
3. From checking everything, interesting to note that with my 'DavidCarr' added to the Admin group and using 'DavidCarr' to log into the Admin Tool, this same 1009: FailPermissionDenied error also occurs for this user on repositories {R5, R8, R9, R16}.
4. Point #3 above is clearly not a good discovery. While a[n annoying] workaround to Obliterate can be achieved by signing in using different users, if there is a repository that cannot be obliterated across all users then there won't be a solution. At present, at least the union of the Rx set in #2 and #3 is empty.
5. Yes, I am certain I deleted the correct files because I checked the Cache_Repository file (opening this, one can see at the beginning what it corresponds to). In the event I made a mistake, I have deleted the whole folder and everything below:
C:\Documents and Settings\DACarr\Application Data\SourceGear\Vault_1\Admin
then repeated the repeated the above process (i.e. checking every single repository) for the 'Admin' user. Same result. Then deleted this off again and tested for the 'DavidCarr' user, same result.
6. There was no other connection to Vault, other than through the Admin Tool, during this process.
OS details
Server: Intel x86 Xeon 2.8 GHz, 2GB RAM
OS: Windows Server 2003 sp1 (build 3790)
SQL: SQL Server 2000 8.00.760
Client: Windows XP Pro sp2
Admin Tool has now been run on server itself, and behaviour is identical (i.e. for Admin user, failing on {R7, R17, R19}, for DavidCarr user failing on {R5, R8, R9, R16}.
I'll send you a private message with the Vault server log file.
OS: Windows Server 2003 sp1 (build 3790)
SQL: SQL Server 2000 8.00.760
Client: Windows XP Pro sp2
Admin Tool has now been run on server itself, and behaviour is identical (i.e. for Admin user, failing on {R7, R17, R19}, for DavidCarr user failing on {R5, R8, R9, R16}.
I'll send you a private message with the Vault server log file.
Hi Beth,
We certainly appreciate your dedication and perserverance in trying to solve this problem.
I think we may have discovered the problem! Another pair of eyes always helps...so I was digging with my colleague Don (who decided upon, and bought Vault for the company) and we have found that when looking at the 'Folder Security' tab, the 'Admin' user has no access rights for the 3 repositories that are generating the 1009: NoFailPermission error. The 'Admin' user DOES have RCA access rights (only checked at the $ root) for all the other 17 repositories.
Similarly, the 'DavidCarr' user is failing on 4 different repositories, and for those that fail, 'DavidCarr' has no access. It seems that within the Admin Tool, the given user must at least have 'R' access to the repository. Giving 'DavidCarr' read-access to one of these repositories then results in no error when looking at that repository on the Obliterate tab.
While this does seem to make sense and things can be fixed for the other users of the Admin group, it doesn't solve why the 'Admin' user has lost folder security RCA rights to those 3 repositories. Further, the Folder Security tab doesn't allow the Admin user's rights to be changed. Is this in a table in the DB?
Thanks,
David
We certainly appreciate your dedication and perserverance in trying to solve this problem.
I think we may have discovered the problem! Another pair of eyes always helps...so I was digging with my colleague Don (who decided upon, and bought Vault for the company) and we have found that when looking at the 'Folder Security' tab, the 'Admin' user has no access rights for the 3 repositories that are generating the 1009: NoFailPermission error. The 'Admin' user DOES have RCA access rights (only checked at the $ root) for all the other 17 repositories.
Similarly, the 'DavidCarr' user is failing on 4 different repositories, and for those that fail, 'DavidCarr' has no access. It seems that within the Admin Tool, the given user must at least have 'R' access to the repository. Giving 'DavidCarr' read-access to one of these repositories then results in no error when looking at that repository on the Obliterate tab.
While this does seem to make sense and things can be fixed for the other users of the Admin group, it doesn't solve why the 'Admin' user has lost folder security RCA rights to those 3 repositories. Further, the Folder Security tab doesn't allow the Admin user's rights to be changed. Is this in a table in the DB?
Thanks,
David
Imported from VSS was cause of problem
Just to close this thread on my end, so that others reading through it can be better served...
It is not definitive, but most likely that the problem was due to an old VSS database. Our Vault database was created and an old VSS database was imported into it. The Admin user did not have RCA folder security rights at the top of the tree for those repositories that originally existed in VSS. As there is no way to change the Admin user folder security, it was never possible to assign viewing privellege, so attempting to view it (in order to obliterate, on the Obliterate tab) was causing the error.
Beth at Support solved this problem by providing SQL scripts to delete off records from specific tables in the Vault DB. I won't specify these here, as I'll leave it to Beth/Support to decide what should be public.
Lastly, I must say that Beth provided the most outstanding technical support I have ever received [in my 15 yr technology career]. The quality and depth of the information and the responsiveness was superb. Her diligence and persistence ranked head and shoulders above any other experience. If Microsoft and other tech companies had people like her, we would all have less lines on our faces and more hair on our heads (at least for those of us in that camp), drink less caffeine, and be getting home at a reasonable hour. Thx.
David
It is not definitive, but most likely that the problem was due to an old VSS database. Our Vault database was created and an old VSS database was imported into it. The Admin user did not have RCA folder security rights at the top of the tree for those repositories that originally existed in VSS. As there is no way to change the Admin user folder security, it was never possible to assign viewing privellege, so attempting to view it (in order to obliterate, on the Obliterate tab) was causing the error.
Beth at Support solved this problem by providing SQL scripts to delete off records from specific tables in the Vault DB. I won't specify these here, as I'll leave it to Beth/Support to decide what should be public.
Lastly, I must say that Beth provided the most outstanding technical support I have ever received [in my 15 yr technology career]. The quality and depth of the information and the responsiveness was superb. Her diligence and persistence ranked head and shoulders above any other experience. If Microsoft and other tech companies had people like her, we would all have less lines on our faces and more hair on our heads (at least for those of us in that camp), drink less caffeine, and be getting home at a reasonable hour. Thx.
David