The Hidden Command That Would Have Saved My Life

... or at least two hours of it ;-) ...

Life Is A Miracle

Sometimes I feel like life is such a precious thing, and every breath you take is like a little miracleon its own. As years go by, we tend to get used to it and take it for granted... But when you start thinking about the billions of cells, organic chemicals, atoms, and complex mechanisms involved in just drawing a simple breath... Waouh... what a wonder!...
So what a waste to spend your time on such trivial tasks as trying to figure out for instance,how to start NetBeans 5.0 with JDK 6, or how to secure a password file on Microsoft Windows XP Home Edition, when there are so much more thrilling things to do?

As I have already hinted about in one of my previous entries, I've been busy preparing an advanced JMX Example for JDK 6 - but this is a topic for another blog. What is the topic of this blog however, is the strange idea I had to test that new JMX example on my own home PC. I am used to Solaris and Unix Systems, but for me, Windows is more like uncharted territory...

Working From Home

Like many Sun engineers, I occasionally take the opportunity to spend a few hours working from home (essentially reading my mail) before driving to work. I'm only doing this once in a while, but it's incredible how much more enjoyable it is to be sitting at home in front of your email, with an orange juice and some jam on a toast, rather than be sitting in your car with all of the morning jam around you ;-)

So as it happens - after having spent some time downloading and installing the latest bits of NetBeans IDE and JDK 6 on my home PC, I set out to test my example.
Well, the first task I had to do was to start NetBeans with JDK 6. As it turns out, and like many other things, it is something quite simple... if you know how. On my Solaris System at work I simply start NetBeans with its --jdkhome option. So I naively tried to do the same...

But on my home PC, things were different: NetBeans would simply start or not start - never giving any error message, but the options I gave were apparently thoroughly ignored.
I tried by editing the NetBeans shortcut on my desktop, then by running it from the command line, then by passing -help, --help, /help, and even toto (yes remember, I'm french), nothing helped.

Then I suddenly noticed the presence of an executable named nb.exe besides the netbeans.exe I was trying to use... And Oh! Wonder of wonders! that one worked!

How to start NetBeans 5.0 with JDK 6 on Windows Platform

So that's going to be my tip #1: if you're trying to start NetBeans 5.0 with JDK 6 on a Windows platform, use nb.exe with --jdkhome="path to jdk-6.0". If the path to jdk-6.0 contains some white spaces, as it usually does if you've installed it in e.g. C:\\Program Files\\Java, then don't forget to surround it with double quotes "..." [back to trivial tasks].

OK, that one was easy to figure out. I'd probably found it sooner if I had read the docs ;-). My guess is that the --jdkhome option didn't work with netneans.exe because I had probably garbled it, or didn't surround my path with "...", but couldn't know what was wrong since that exe isn't supposed to print any error message.

The real trouble came when I tried to start my example with a secure configuration: As I had expected, the JVM refused to start, giving the following message:

    Error: Password file read access must be restricted: src/etc/

But how do you restrict file access on Windows XP Home Edition?

Well, if you're in a hurry, you may want to jump directly to the solution, or jump back to the trivial tasks at the beginning of this article. If however you're ready to spend a few of these miraculous breaths with me, then please keep on reading ;-)

As I was saying, the JVM error message didn't surprise me: I was expecting it. It is even something I had documented in the example. And I had even put a link to a document that explained how to secure a password file on Microsoft Windows Systems. So I dutifully clicked on that link and started following the instructions. The catch is: these instructions actually apply to Windows XP Professional Edition. On Windows XP Home Edition, they do not work. There's no way you can make the damned Security tab appear.

Like many Windows XP users, I didn't know that there was an actual difference between XP Home and XP Pro. I thought it was just a question of pricing and support. It's not.

So my first idea was that to make the security tab appear, you had to have several users configured on the machine.

    So I dutifully added a new guest user.
    ... No changes.
    Then I thought I might have to reboot.
    ... No changes.
    Then I thought I might have to set up a password for each user.
    ... No changes.
    Then I thought I might have to reboot.
    ... No changes.
    Then I thought I might have to share the folder.
    ... No changes.
    Then I thought I might have to copy the folder outside of any user space (for instance, directly on C:\\).
    ... No changes.
    Then I thought I might have to reboot.
    ... No changes.
    Then I thought I might have to reboot again.
    ... No changes.
    Then I thought I could google for the information on the internet... Ahhhhh what a mistake ;-)...

At that point, I had finally figured out that there was indeed a difference between Home and Pro, and that I was only running the Home Edition. So I started searching for pages explaining how to secure a file on Microsoft Windows XP Home Edition. I found out several documents explaining that this feature was not part of XP Home, then found some links on some commercial products offering to add that feature on top of XP Home, then found a link which proposed to download and use an NT binnary to do the trick - with the scary advice to make sure to create a System Restore point before proceeding.

Well, that's my home PC! Pas question de le bousiller!

So finally I did what I should have done right from start: I asked my colleagues :-). And Mandy actually came back with a very simple solution: use cacls

Using 'cacls' to secure a file

It stands in one line:

       cacls path-to-file /P username:R

That's it! Just open a command window (cmd.exe) and type in the command! Can there be any thing simpler?

And you know what? There's even a cherry on the cake: it seems that this simple cacls command can be used with most Windows Systems: my internet search reveals links to XP, NT, 2000, 2003, 98, and even 95! Could that be right?

Breathing again...

Well now that the problem is solved, let's perform some small miracles, and breathe again ;-)))

Once I had figured out how to start things that needed starting, testing the example itself was a piece of cake. Ah! If only all OS commands were portable like Java APIs :-)

-- daniel
Post Scriptum: There's still a catch though: AFAIK cacls doesn't work on Fat32 - your file must be on an NTFS partition - which fortunately seems to be the default on Microsoft Windows XP Home Edition.

I have downloaded the latest Sun JDK on windows - but for the life of my I cannot figure out if it is working. I neede it for something else and I am perplexed as to how it is to work.

My grip is that many of these advanced tools take long to get up and running for other applications - and they should not - complete lack of user configurability.

Posted by Frustrated newbie on November 03, 2007 at 11:36 PM CET #

I have xp pro and an NTFS file system, but this didn't help. Anyone else have any other suggestions?

Posted by John Windberg on November 21, 2007 at 05:02 PM CET #

Hi John,

Do you mean that cacls didn't work, or that the out-of-the-box connector still complains about the password file permission not being correctly set?

I believe the M&M faq has now been updated with detailed instructions on how to set the password file permissions.

Hope this helps,
-- daniel

Posted by daniel on November 22, 2007 at 02:32 AM CET #

The cacls did work, as far as I can tell.
The out-of-the-box connector still complains.
Thanks for the link, I'll go read it and find out if it helps.

Posted by John Windberg on November 22, 2007 at 08:18 AM CET #

This really needs to be updated for newer Windows versions. On windows 7 it appears you need to use icacls and not cacls.

icacls jmxremote.password /grant:r some_user_name:RW
icacls jmxremote.password /grant:r some_user_name:(R,WO) - WO is Write Owner

Either way neither of these work or calcs worked fully until I used explorer's advanced settings and made the some_user_name account the only owner. The confusing thing is the bottom icacls command should have done this!

Posted by guest on May 13, 2013 at 07:54 PM CEST #

Post a Comment:
Comments are closed for this entry.

Daniel Fuchs blogs on Scene Builder, JMX, SNMP, Java, etc...

The views expressed on this blog are those of the author and do not necessarily reflect the views of Oracle.


« July 2016