Here's one for you . . .

Two days ago the users reported that the New Terminal menu item in the desktp context menu no longer brings up a new gnome-terminal. They are using gnome 2.2.2 (or at least that is the version of the gnome-desktop rpm installed on the machines with RedHat WS3. This is the latest package offered by rhn for this version of RH.

I can't seem to find an easy way to verify if the code behind the menu is still valid. I suppose I could try to re-install the gnome-desktop package if I new that was indeed the correct one. Of course, this menu is not one that can be edited through the GUIs.

Main Menu-> System Tools-> Terminal does indeed bring up the terminal as does gnome-terminal from an existing terminal. So, the exectuable itself is still good.

I have been able to use gconf-editor to set up a keyboard shortcut as a temporary work-around. But the thought of having to implement that for each user makes me tired.

Thanks in advance for your assistance.

This functionality (context menu terminal option) exists in Gnome versions up to 2.10, but not in 2.12. I don't have 2.12, so I can't say for sure, but read it is gone from the menu in 2.12. Don't know if RH has patched anything in their distro that would be different than in any other version. There is a graphical tool in Gnome 2.10 for setting keyboard shortcuts, but that doesn't help your multiple user issue. From the Gnome web site:

" Some old features in Nautilus, such as the Open Terminal, that would be available on the desktop context menu, have now been moved into more powerful extensions, with more functionality for the power users that need them."

Thanks Sargek for your reply. I've read about the change to this menu item in versions of gnome beyond 2.10 as well. However, from what I can see, version 2.2.2 is what is include with the version of RH WS on our machines. Even so, the gnome packages have not been updated recently. There is no evidence that I can see indicating a software change triggering this problem. Further, the menu item is still in the context menu. If functionality had been moved, I can only assume its associated menu item would be moved as well.

I've also read that customizing this context menu is not possible. But, does anyone know how I can confirm that the code behind it has not been corrupted.

Finally, I thought I had created a keyboard shortcut to enable users to bring up a new terminal window. But it only seems to work when any other window is active. If there are no windows open on the desktop, the keyboard shortcut doesn't work. ARGH!!!

RH must have a tweaked version of Gnome, or their own version numbers because Gnome itself is only on 2.1! Anyway, what are the settings under "Preferred Applications" for the terminal? I assume they are the gnome-terminal, which is the default. At first I thought since this is a Workstation version, there may be facilities to lock it down so users cannot use the command line, and there are, but I believe when this is done, the context menu item disappears, which is not true in your case.

As for the code being corrupted, that can't happen since there is no code running on the system, only compiled binaries. I can't help but wonder if a setting is wrong, or something. I searched gnomesupport.org and google'd, but didn't find anything either. I will keep looking and see if I can find something - if I do I'll post back.

I certainly appreciate your persistence. I agree it seems like a screwed up permission or user setting. But, how each user managed to do the same thing to cause the same problem is beyond me.

Thanks again.

Maybe I missed something entirely - since all of your users reported it, perhaps a security or other patch removed this functionality? Have you pushed out any patches lately? If it was a setting, why would all users report it, unless of course, you have gremlins...!

Not gremlins, trolls. I no nada about pushing any patches or updates out. Even so, I've rechecked the logs to see if anything was done automagically. Nothing is being reported in the log files. A few a the machines have also since be rebooted. Things with the menu item remain hosed. I am perplexed.
TU.

Well I obviously *know* nothing after this last post. Ack!

After months of never understanding what happened, a different problem caused me to stumbled over the source of the issue in this post. Somehow, in one of our automounted directories, directories are being created with the same name as key executables. Worse yet, these directories are owned by root. How it happens I do not know. But, because the automounted dir is in the user's $PATH, the system tries to execute the directory named as the executable. Of course it fails, but there is rarely a warning anywhere. All I had to do was remove these directories, and the original command files are found and executed. Here's an example . . .

Notice all the directories owned by root have the same names as an executable (df, sh, gnome-terminal). The directories themselves are empty. Delete the directories and everything goes back to normal. Cool.

Not really. They get re-created and I can't figure out what the trigger is!! The only clue I have going for me at this point is the date and time that the directories are being created. But, because this particular directory is automounted to several other systems, I really have no idea which machine the actually creation is happening on let alone what user.

Has anyone ever seen anything like this?!?!?!?

Glad you found a reason...sort of! I am not a big GNU/Linux network guru, so I may stumble through this - are you guys using an NIS/NFS network? I am thinking of a mounting script in /etc that lets the system know what to mount and not to mount, but haven't looked at an NFS system in a couple of years. Not /etc/fstab, but something else - I do not have either NIS or NFS support installed in this box, so cannot say. Just trying suggestions to maybe stir up some thought...

I'm certainly no Linux expert myself and I've caused more than enough havoc on my share on Solaris boxes. That is how I cut my teeth with this UNIX stuff, so Linux never fails to throw curve balls at me.

At any rate, yes, we use NFS and NFS along with the automounter. You should check out the automounter (/etc/init.d/autofs) for the mounting and unmounting scheme you mention. Autofs seems to be fairly stable on Linux, or at least on RedHat AS 3.0 which we are using.

The automounter has this feature named ghosting that I suspect may be the cause of the core issue at work with my mystery directories. We shall see, I'm going to turn this "feature" off tonight and see what happens. None of my searches here, or on google, or RedHat's support site, have turned anyhthing useful.

Good luck and thank you for your help.

You are welcome. I have only set up one NIS/NFS network, and it was small. I used RH 9 for both the server and workstations, and it worked well, with the user's /home dir's being on the server so the users could be totally mobile. That was a long time ago though, and I don't remember a whole lot about it.