Locking is not possible in the directory C:\eclipse\configuration\org.eclipse.osgi

Question

I used to have Eclipse 3.5.2 working from my Limited User Account (i.e. not Administrator).

But when I upgraded to 3.6.2, Eclipse refuses to run in the Limited User Account (it only runs under administrator).

It issues the following error:

Locking is not possible in the directory C:\eclipse\configuration\org.eclipse.osgi. A common reason is that the file system or Runtime Environment does not support file locking for that location. Please choose a different location, or disable file locking passing "-Dosgi.locking=none" as a VM argument. C:\eclipse\configuration\org.eclipse.osgi.manager.fileTableLock (Access is denied)

Well, I checked the owner of that folder (Windows XP) and it is the Administrator, so of course access would be denied.

But... why didn't this happen in Eclipse 3.5.2?

I could probably workaround this by assigning ownership of the entire C:\eclipse\configuration\org.eclipse.osgi but without understanding why, I don't know whether I would need to do that for additional folders.

Another workaround is to do just as the error message suggests: Disable file locking passing -Dosgi.locking=none as a VM argument. But I don't what the tradeoff would be (locking is there for a reason, right? What is it?)

If I understand what the purpose of that locking is, I can wisely choose one of the 2 workarounds outlined above.

Answer 1

This has to do with running Eclipse in a multi-user environment, first read this Eclipse help section on multi user installations. When Eclipse was installed, it was done so as an admin account. This meant that the configuration folder was accessible and Eclipse thought this was a shared configuration or private install. Because of this Eclipse will first try to write data to the configuration catalog, but will fail for normal users.

What you want to do is to make Eclipse realize that you have a shared install installation and that all configuration data should be in the users home directory.

See this similar question and this IBM support answer for more information.

Answer 2

I had the same problem with the Juno version.

Several years ago I made a multiuser environment that worked perfectly, but the things changed with time. Now, my obvious solution, to change permissions, didn't work at all.

The issue is that the lock files have special permissions that the 777 won't change. Also, it is not the best solution just to provide the 777 to a directory inside any UNIX system (Linux, AIX, etc.); then, I worked around to another solution.

Inside the Eclipse directory you can find a eclipse.ini file. There you can put the vm arguments, although the one suggested by Eclipse won't work.

My environment started working with this one:

-Dosgi.configuration.area=@user.home/.eclipse

This way, each user inside the environment that run the Eclipse program, will create a different .eclipse directory inside the particular home, with full rights and zero problems.

I expect this to be useful for everyone "in the UNIX side".

Answer 3

Proper fix

Make sure you update the permissions of Eclipse and the workspace to whatever user Eclipse runs as. You can use ps -ef | grep -i eclipse while eclipse is running to find that user. Once you have the user, you can easily use chown -R user:group ~/Documents/workspace**

Hacky fix

1. Change permission of eclipse itself wherever you have it installed (in my case /opt/):

   sudo chmod -R 770 /opt/eclipse

2. Change permission of workspace wherever you have it located (in my case ~/Documents/):

   sudo chmod -R 770 ~/Documents/workspace

Hope this helps my fellow Linux users!

You can try this on windows with the proper syntax.

Thanks to Frederik for your help!

Answer 4

I wouldn't chmod to 777 to fix this problem. In my case the owner was root:root after a Rational Team Concert install for some RTC files and not my userid. Go to your user's home directory and ls -ltr to see what your userid and groupid are (on Ubuntu mine were both the same) and then execute the following on your eclipse subdirectory

sudo chown -R myuserid:groupid /opt/ibm/eclipse

Answer 5

I had this problem when trying to create a workspace in a mapped network drive.

One option is to start Eclipse from terminal with ./eclipse -vmargs -Dosgi.locking=none.

Another option is to add osgi.locking=none to the config.ini file in Eclilpse's configuration folder.

The second option is more convenient, but has the side effect of allowing any number of Eclipse instances running the same workspace.

Answer 6

Who has write access to the directory: C:\eclipse & C:\eclipse\configuration ?

AFAIK eclipse decides, on startup, whether to use the central installation as the configuration location, or a user accessible directory based on whether the eclipse (or possibly the configuration) directory are writable.

Answer 7

simply copy and paste your eclipse folder to a folder in your currently logged in user space (in case you are having hard time finding one of the correct folders, just put it in C:\Documents and Settings\your_user_account_name) .And create a new workspace folder there only. Worked for me....!

Answer 8

I simply added osgi.locking=none in the config.ini file, it started working. Thank you all for your help..

Answer 9

Here is another reason why this message appears. It may seem an obvious thing to check, but if the read-only flag is set on the .fileTableLock file (this is in Windows, don't know about Linux) then you'll also get that Access Denied error. This arose because we were unzipping a pre-configured workspace and configuration into our users' IDE environments.

Answer 10

Well on windows, a simple work around for the same is to start Eclipse as an Administrator.

Right Click on Eclipse icon and click on Run as administrator.

It will solve your problem.

Enjoy :)

Answer 11

I had a similar problem running on a server WITH an admin id.

Lowering UAC and rebooting the server fixed it.

Answer 12

On Windows, the same error message occurred for me because I turned UAC back on after 2 years of having it off. I just deleted the . lock file eclipse complained about.. and pressed Continue when the UAC popup came.. and then re-opened eclipse.. all was well.