31

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.

ateiob
  • 9,016
  • 10
  • 44
  • 55

12 Answers12

16

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.

Fredrik
  • 10,626
  • 6
  • 45
  • 81
  • 2
    Excellent references, thank you! My installation is neither shared (it's not on a server! I'm the only user on this laptop) nor truly private (I always install any software as Administrator but only use it under Limited User Account). The IBM support answer you provided is really the 1st **workaround** I described in my original post (except that it's for AIX/Linux, not Windows). Is there any way to tell Eclipse to start using a per-user config directory, after this problem already happened? – ateiob Dec 02 '11 at 12:22
  • 4
    @ateiob Yea, it should be possible. Try using a fresh workspace and disabling write access to the configuration area. The workspace will probably already be associated with it the shared configuration dir, so that may be the issue. You can also startup with the argument "-D osgi.configuration.area=c:\my_home_dir" – Fredrik Dec 02 '11 at 22:51
  • 1
    I finally got around to implementing a fix and testing it. I ended up choosing to add my LUA to ACL of the entire `c:\eclipse\configuration`. The reason I chose this solution over the others you suggested is that trying a fresh workspace while disabling write access to the configuration area is an *experiment* I don't currently have time for, without much added benefit to my understanding of the system and/or to the Eclipse community, not to mention that this may change in the next release of Eclipse... – ateiob Jan 05 '12 at 13:13
  • 1
    Your 2nd suggestion (startup with the argument `-D osgi.configuration.area=c:\my_home_dir`) is as good as the workaround I chose, but I preferred not to modify the shortcut in a way that would be hard for me to remember what I did when I upgrade Eclipse. Thanks a million and accepting. – ateiob Jan 05 '12 at 13:16
15

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".

jonsca
  • 10,218
  • 26
  • 54
  • 62
Marco Alvarado
  • 151
  • 1
  • 2
8

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!

Community
  • 1
  • 1
saada
  • 2,612
  • 3
  • 27
  • 33
  • 3
    very bad, I think,, 777 should always be avoided – ericn Aug 30 '13 at 02:58
  • 2
    granting permissions to everybody should not be the solution. You should always apply Principle of least privilege. – Matto Dec 30 '13 at 23:54
  • 1
    @fuzzybee How many people do you know who use eclipse on a data center server ? 777 is NOT a issue with developers since they are working in their own environment and there is only one user on that desktop. Its NOT a issue. This is a good solution. Its advice like this that makes ubuntu a "non" preferred OS for many. – Siddharth Jan 21 '14 at 04:28
  • 1
    the main issue about 777 is not a local one - 777 grants rights to EVERYTHING and EVERYONE, including embedded samba-servers in IDEs, webservers which are locally used to test things and so on and so forts - 777 ist most likely the dumbest thing to do in linux and everyone who actually think that its a "good solution" has no clue about *nix operating systems. 770 is much better - IF the computer is within a restricted & secured LAN with only limited WAN-access. – specializt Mar 27 '14 at 13:48
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
Jon Lin
  • 142,182
  • 29
  • 220
  • 220
Alexandre Polozoff
  • 41
  • 1
4

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.

ems
  • 722
  • 1
  • 9
  • 16
  • Putting this to the config.ini was the perfect solution for me, since I could not just create a link to the eclipse.exe and also was not able to pass the arguments via command line in our build environment. – Matthias Sep 11 '14 at 07:51
2

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

Sikander
  • 162
  • 4
  • This does not add anything to the answers already on this question. Please do not add answers just to say "me too" or "didn't work for me" type of comments. – Chris Hayes Jun 19 '14 at 05:06
  • 1
    @Chris : No offense but why are you trying to be the stackoverflow pundit ? I see the comment quite valid and Sikander shared his personal experience. – Wahib Ul Haq Jul 01 '14 at 23:01
  • 1
    @WahibHaq SO has a quality bar and rules/guidelines for a reason. If you think this isn't appropriate behavior, feel free to ask about it on Meta. Answers like this one add nothing to the site and just add more cruft for people to sort through when they get here via search results. – Chris Hayes Jul 02 '14 at 04:41
1

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....!

rahil008
  • 173
  • 1
  • 7
1

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.

Matthew Wise
  • 2,639
  • 26
  • 23
1

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 :)

Umesh Patil
  • 4,668
  • 32
  • 24
1

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.

James Blackburn
  • 4,492
  • 2
  • 27
  • 24
  • 1
    As I mentioned in my original post, it is owned by Administrator. Do you know how to tell Eclipse to use a user accessible directory for the configuration? Right now, Eclipse simply refuses to run after issuing this message. My current workaround currently is to use it from the Administrator account, but this is like working all the time logged as 'root' in UNIX/Linux... – ateiob Dec 02 '11 at 12:16
0

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

Lowering UAC and rebooting the server fixed it.

englebart
  • 563
  • 4
  • 9
0

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.

hamish
  • 1,141
  • 1
  • 12
  • 21