We're experiencing strange permission issues with SVN after switching from Windows Server 2003 to Server 2008.
On our standard build box there is a folder (C:\SVN_Code_Folder) which AD_User_A associates with a SVN repository using SVN_User and TortoiseSVN 1.7.6
When using Windows 2003, when AD_User_B logs into the box and tries to Update, Switch, Merge the SVN_Code_Folder with SVN_User, the command is executed.
It Windows 2008, it fails with the message:
Command: Update
Error: Working copy 'C:\jboss-4.2.3.GA\server\New folder' locked
Error: sqlite: attempt to write a readonly database
Error: sqlite: attempt to write a readonly database
Completed!
Attempting to unlock the file, which was never locked, via the context menu is met with the following message:
There's nothing to unlock. No file has a lock in this working copy.
I've played with the permissions of the folder and I've discovered that giving "Domain Users" control over the folder fixes the issue, but I would prefer to not have such a broad permissions. I've tried granting the same permissions to individual users and a SVN-group, but these too did not work.
What am I missing?
Is this an improper use of SVN?
Can 2 different Domain users update a folder using SVN without removing the .SVN file?
For future reference...
I had this same problem with some WC's that I copied over to my new laptop's hard drive, from a file share on my old machine.
It turned out that the problem was solved by giving myself (as opposed to all domain users, or any other group) full control over the folder.
Did you check the svn service user on the win2008 machine?
Does that user have local administrator privileges and also have permission to these folders on c:?
After changing anything restart the service.
For me change folder permissions did't help, but I have update for several directories in a batch script so I solved this by
cmd -> Run as administrator -> start update script
Related
Been using Git Gui on Windows on a work computer for over two years now. Last night the repo was working fine, but this morning after a reboot, Git Gui pops up a message about "permission denied".
No idea what changed, although we did get an email saying that a corporate antivirus update had been pushed out which required a reboot. Also, a Windows update for December 2022 was installed on my machine which also required a reboot.
The full error message is:
couldn't open ".git/PREPARE_COMMIT_MSG": permission denied
couldn't open ".git/PREPARE_COMMIT_MSG": permission denied
while executing
"open [gitdir PREPARE_COMMIT_MSG] a"
(procedure "run_prepare_commit_msg_hook" line 8)
invoked from within
"run_prepare_commit_msg_hook"
(procedure "rescan" line 27)
invoked from within
"rescan ui_ready"
(procedure "do_rescan" line 2)
invoked from within
"do_rescan"
("after" script)
Things I have tried:
Based on suggestions in threads with similar "permission denied" errors, I ran the follow from a command prompt:
icacls "path\to\Work.git" /grant MyUserName:(OI)(CI)F /T
The command executed without errors, but no change to the repo.
Ran Git Bash (MINGW64) which runs without any immediate errors but only git status works. git add gives the error fatal: Unable to create '/path/to/Work/.git/index.lock': Permission denied
Tried a separate, personal, repo on the same work computer for a repo hosted on github.com. That worked fine (can commit, pull, etc.).
Any thoughts? My user account is part of the Administrators group, but it looks like the Windows and "corporate anti-virus" updates have modified or blocked something to do with my user account.
UPDATE 1
Rebooted Windows into Safe Mode. Now I can git add and git commit, though git push fails due to a failure to resolve dev.azure.com (something to do with the network not loaded in Safe Mode). Rebooted back into normal Windows and the problem returns: git add and other commands fail immediately and git push finds dev.azure.com but I get a permission denied error.
UPDATE 2
Based on the comments from #LeGEC, I checked the repo .git folder. There is no PREPRE_COMMIT_MESSAGE or index.lock file. The permissions haven't been touched by me, but after explicitly allowing my user "Full Control" over the folder, its still not working - still "permission denied" errors.
A colleague does not use Git for Windows, and was not having issues after the recent update. He suggested I try Visual Studio (which is tied directly into dev.azure.com)...and git works from Visual Studio 2019!
So we think that recent anti-virus or group policy changes has revoked, blocked or broken authentication of my user (presumably) connecting to the corporate network's and/or dev.azure.com. Somehow Visual Studio is able to authenticate me (through the Mcicrosoft Azure account?) which fails when using my Windows account....does that make sense?
Will update this question as and when I find out more details.
If anyone has seen this type of thing before (suddenly one application stops working with git with "permission denied" errors, while another works), your input would be appreciated!
first-time asker here. I have an issue with git, cant clone anything. If I don't specify where to clone, this will appear.
> git clone https://gitlab.corp.cz/username/project_name.git project_name
fatal: could not create work tree dir 'project_name': No such file or directory
If I first create a folder via explorer, then the error message is different.
> git clone https://gitlab.corp.cz/username/project_name.git project_name
Cloning into 'project_name'...
C:/Users/username/Documents/project/path/.git: No such file or directory
Mkdir say the same, though not sure if windows even have a mkdir. At least a month ago, it worked. Please help, even reinstalled windows, didn't help.
EDIT: It looks like it is not a git problem. I cannot create any file using nothing other than windows explorer. Checked and I have write permissions for this folder, so most likely a windows problem.
a) You must run the command in a directory where you have write permission;
b) Add git to the list of allowed applications:
1 - Select Start > Settings > Update & Security > Windows Security > Virus & threat protection.
2 - Under Virus & threat protection settings, select Manage settings.
3 - Under Controlled folder access, select Manage Controlled folder access.
4 - Switch the Controlled folder access setting to On or Off.
c) If that doesn't work, try running the terminal with the administrator.
If you are using WSL (Windows Subsystem for Linux) to execute this command in the terminal check if the linux user has permissions to create a new folder there or try doing it as root.
If you are using Powershell or the Command Prompt try running it as Administrator and check if cloning a repo will work.. if this works there is a problem with your permissions. In this case try to change your working path so if the folder you are trying to clone a repo is in "C:\Program Files" or "C:\Program Files (x86)" try cloning to another place as these paths cause problems.
I'm looking for help !!
I am getting the following error message when trying to complete a git pull;
C:\Jenkins\Repo> git pull error: cannot open .git/FETCH_HEAD: Permission denied
The machine in question is Windows Server 2008 r2 OS and were using ssh to handle the authentication.
We have tried the following;
Checked that the current user the correct read/write on the FETCH_HEAD file, which it does, also checking that the user has the correct permissions set on the repo root.
I have tried to load my private key (which I know 100% works and has permissions to the repo in question) and still the same issue... so from little I know regarding git I think this is more of a Windows issue
and lots of Google !
Any more ideas on what to do/check would be a great help !
This happened to me after I upgraded to Windows 10. While my user is an administrator and Administrators had full access to the root repo folder, my user was not explicitly listed. I've added my user with Full Control and it solved the problem for me (had the same issue with Outlook refusing to read the PST file until I did the same thing).
So, for me, the solution is:
Right click on the folder, select properties
Security
Edit
Add
Type in my user name
Check Full Control under Allow
OK, OK
On Windows 10 this is what worked for me:
1. go to the repo folder
2. right click on the .git folder and choose the last option - properties
3. on the general tab uncheck hidden checkbox if checked
4. hit apply and then ok
now go try git fetch or git pull and it should work.
This is fairly a common problem. I've come across it many times and almost all of the times, the issue is with the right permissions to the repo/directory .git/ and the right SSH keys to access the git repository.
You probably need to make the user, the owner of the repository chown (Give full access to the user) or, clone the repository to a different directory.
You can set the write permission with the following command
go to your folder chown -R youruser:yourgroup .git/
Also try to un-hide the .git folder.
In my case, this happend because I hide the .git folder by hand(usually it will be hide automatically) but I forgot it.
I have tried edit security but no effect. So I just show the .git folder and solve the problem.
May this can be help for someone
This happened to me because after updating windows.
Kindly try these steps:
Right click on folder -> properties
Under general there are two checkbox hidden and read only -> uncheck the hidden check box and click on apply
Under security -> edit -> add user -> apply
give full access to your user
This will work for you
just remove the folder,and clone again.
What I did was open powershell / command prompt with Administrative rights inside the repository, and I was able to pull / fetch / merge and push.
This problem can also be caused by the caches Jenkins keeps of it's Git operations. I had tried chowning the files I thought were causing the problem, I also deleted the workspace completely.
After deleting %ProgramData%\Jenkins\.jenkins\workspaces\MY-BUILD* I still had the exact same error message.
In %ProgramData%\Jenkins\.jenkins\caches I deleted everything but you could probably just delete the git-<HEX_ID> and git-<HEX_ID>#tmp folders and retry the same checkout. This resolved the issue for me as Jenkins was forced to recreate the .git folder in both the workspace and the cache and the permissions were then correct.
Steps:
Delete the workspace folders of the troublesome job
Delete the Git caches
Retry the job
I am trying to get a symlink working over a network drive.
I have already tried suggestions on questions already asked, such as running as administrator and checking if the directory already exists. Unfortunately it still gives me the following error:
C:\Windows\system32>mklink /d \\myserver\someLink \\myserver\mydir
Access is denied.
Any ideas how I could get this working? The local machine is running windows 7 and the remote machine is running windows server 2008 R2 standard.
I jumped through all the hoops:
Create a non-admin account (in my case, activated the guest account).
As Admin, run secpol.msc and grant this account Create Symbolic Link permissions.
runas /user:guest cmd to open a command window as the guest.
only to get caught on the simplest problem: because I was running as guest, I didn't have write permissions within the directory. So,
As admin, change permissions in the target directory (where you want to make the link) to give write access to the non-admin user.
I had this while I wanted to create a hard link with mklink /H ....
By removing the /H, the error vanished as well.
So if a symbolic link does the trick for you as well, you should try this.
This is a little silly, but make sure you're using /D (soft) or /J (hard) for directories or you'll get access denied.
I have a Jenkins job that calls a batch file on a ClearCase drive (V:).
My Jenkins slave agent is running as a service using a local admin account.
The Jenkins job does the follow:
cleartool startview MY_VIEW
cd /d "V:\MY_VIEW\Build"
call PrepareBuild.bat
When I run the Jenkins job, I keep getting "Access is denied." in the Console Output when it tries to call the batch file. However if I manually run the above in command prompt, it completes successfully.
I did not have this problem under Windows XP. Does anybody know why this is happening on Windows 7 (32-bit)?
Thanks.
The V:\ is a virtual drive obtained with the windows command subst.
It is a shortcut between the root directory of your dynamic view (M:\yourView) and the virtual drive.
(Ie, V:\ is not particularly linked to ClearCase. It is just a drive letter the user wishes to associate to a certain ClearCase view root directory)
However, ClearCase registers that association in the registry HKCU/software/atria/....
Which means the ClearCase session run under the local admin account for Jenkins won't know about said association and the need to restore that virtual drive.
A workaround would be to make that drive permanent, using psubst.
That register the drive path in [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\DOS Devices], and HKLM is accessible from all accounts.
See " How to make SUBST mapping persistent across reboots? "
I had the same problem. Had a simpler solution.
Jenkins doesn't have access to folders that only the user has access to (even though its run by the user). So the folder which is getting access denied you need to set folder permission to everyone not the user