ducman Posted February 23, 2013 Report Share Posted February 23, 2013 Plastic SCM 4.1.10.391 AD security MSSQL 2012 Server install and working for administrator new user specifically added to repository and workspace with all rights in Plastic new user specifically added to dir\files rights new user added integrated security MSSQL Client session unable to connect to workspace with error: "Access to the path 'c:\xxxxxx\.plastic\plastic.wktree' is denied Please advise Link to comment Share on other sites More sharing options...
manu Posted February 25, 2013 Report Share Posted February 25, 2013 Hi! it seems that the client can't access to the workspace due to permissions. Grant all the permissions for your Plastic SCM workspace and the client will be able to start-up. Link to comment Share on other sites More sharing options...
ducman Posted February 27, 2013 Author Report Share Posted February 27, 2013 I can grant right to the new Repository but i can't find where to grant specific rights to a specific workspace. AD user granted file permissions.. I'm new to Plastic SCM and as i see it, workspaces are shared enviroments for code development? If i have several projects in the same repository i should be able to create new workspace for each project and assign specific developers to specific workspaces? Link to comment Share on other sites More sharing options...
ducman Posted February 27, 2013 Author Report Share Posted February 27, 2013 if i right mouse and run the Plastic GUI as administrator i can get the user into the Respository/Workspace.. its a workaround but a security issue Link to comment Share on other sites More sharing options...
manu Posted February 28, 2013 Report Share Posted February 28, 2013 Hi Ducman, I mean, grant permission in your windows directories, it's an issue with the permissions on your "c:\xxxx" path. That's why if you start the GUI as Admin you solve the issue, the windows Administrator user is having the read and write permissions granted in that dir. Link to comment Share on other sites More sharing options...
ducman Posted March 4, 2013 Author Report Share Posted March 4, 2013 doesn't work.. i've granted the user full admin rights in ALL the development directories. still no joy.. user specifically added via Plastic for repository and workspace.. i failed to mention that we are running this under Win2k8 remote sessions.. AND if user creates new workspace using right mouse admin to open SCM i can't see the new workspace? Link to comment Share on other sites More sharing options...
manu Posted March 5, 2013 Report Share Posted March 5, 2013 Hi, doesn't work.. i've granted the user full admin rights in ALL the development directories. still no joy.. It's still strange that the Windows Administrator account is able to read/write in the workspace path and a regular user (with the permissions granted as you said) not. Can you try to create the workspace in a different location? Maybe the Desktop, just to test if your regular windows user is able to use that path. At the end of the day the Plastic client is just a process that's started with a certain user, the IO operations made by the Plastic SCM client are done by the user that started the process so if the Administrator user can work it must be something related with the Windows security. AND if user creates new workspace using right mouse admin to open SCM i can't see the new workspace? Each windows/linux user has their own workspaces list, so, if you create one workspace with the admin user it's stored for the admin session. You will find the workspaces list inside a file called "plastic.workspaces", this file is located in the Local user directory (C:\Users\XXXXX\AppData\Local\plastic4). If you copy this file and you place it into the cm.exe location path ("C:\Program Files\PlasticSCM4\client" by default) all the system users will share the workspaces list. Link to comment Share on other sites More sharing options...
gweronimo Posted May 30, 2017 Report Share Posted May 30, 2017 Hi there! I'm reviving this old topic since I had a very similar problem, and it may help someone. Due to changes in our Active Directory I had to create a new Windows user profile for myself on my Windows PC. To avoid having to reconfigure Plastic SCM, I copied the %LocalAppData%\plastic4 folder from the old profile into the new one. When I started the Plastic client I got the error box "Access to the path 'c:\wkspaces\myrepo\.plastic\plastic.wktree' is denied." and I could not work with any of my workspaces that were created using my old user profile on the same machine. When I looked into this problem I noticed that, for all my workspaces, only the ".plastic\plastic.wktree" file was inaccessible - I could not even read this specific file into a text/binary editor. However, all the surrounding files could be read (for example ".plastic\plastic.selector", any file inside the workspace, etc). By comparing the Windows Security properties of this old plastic.wktree file with surrounding files and also with the corresponding files in a new workspace created using my new user profile, I noticed a difference: The plastic.wktree file has Security Inheritance disabled, while the other files have it enabled. Instead, the plastic.wktree file has explicitly added the creating user as Owner and with Full Control. It also has added SYSTEM and local administrators with Full Control. Even though my new user profile is a member of the local Administrators group, it seems that UAC is preventing me from reading the file. By either enabling Security Inheritance for this specific file, or explicitly adding my new user with Full Control for this file, I could then read the file and the workspace started working in Plastic again. Link to comment Share on other sites More sharing options...
gweronimo Posted May 30, 2017 Report Share Posted May 30, 2017 For the record, another way to workaround the problem I had was to disable the following Local Security Policy: Local Policies - Security Options - User Account Control: Run all administrators in Admin Approval Mode According to the following forum thread: https://serverfault.com/questions/646691/user-in-administrators-group-has-not-the-same-rights-as-administrator-win-2012 "This could be caused by User Account Control, a feature (hated by many) which makes so that, even if you have administrative rights, you don't actually have them unless you explicitly request them." "by default, the built-in Administrator account is not affected by UAC, while all other administrative users are; thus, it's possible for an administrative user (different from the built-it Administrator) to not actually have administrative rights, even if it's a member of the Administrators group." Link to comment Share on other sites More sharing options...
manu Posted May 30, 2017 Report Share Posted May 30, 2017 Thank you really much for the info! I hope the community find this as much as useful as I do. Link to comment Share on other sites More sharing options...
gweronimo Posted May 31, 2017 Report Share Posted May 31, 2017 14 hours ago, manu said: Thank you really much for the info! I hope the community find this as much as useful as I do. You're welcome! It seems to be the Plastic client that creates the plastic.wktree with these differing access rights, different from the other files it creates in a brand new workspace. (I double-checked by creating one from scratch.) Is this by design - is there a special reason for this difference in security properties? Or would it be possible to instead make the Plastic client create this file with the same rights as the rest of the repo? Link to comment Share on other sites More sharing options...
manu Posted May 31, 2017 Report Share Posted May 31, 2017 I think there's no reason to create that file different from the others... I'll share this with the team in order to check if we can change it. Thanks again for your time looking into it. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.