Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

Java problem with Big Sur

Cave Man

Cave Man

macrumors 604
Original poster
Feb 12, 2007
7,130
333
Neander Valley, Germany; just outside Duesseldorf
I migrated to Big Sur using Migration Assistant from a Time Machine volume and a software package I use that depends on Java will not launch. It gets most of the way through, then I get an alert "Unable to start Graphical User Interface" and I have to quit. What's peculiar is that if I log in as root it works just fine. Any ideas how to get around this problem? It seems it must be a permission issue of some kind.

UPDATE: So, on a whim, I created a new user account with administrator privileges (like my normal account) and the software runs just fine. So, what could be causing this problem?
 
Last edited:
Are you running this in a terminal so that you can see the full output as it starts up? If so, then what happens with a successful launch at the same point that the failure in the unsuccessful launch occurs?
 
It's possible that an executable or a library in either the app or the Java subsystem doesn't have the correct permission bits for non-admin users.

Admin users are members of at least one group that non-admin users are omitted from. The actual group name might vary across various OS releases, but it used to be named 'admin'.

If the group permission bits of the library or executable are correct for the admin group, and the group assigned to the file itself is the admin group, then those permissions apply when an admin user runs the app. Non-admin users aren't members of that group, so they get the "other" permissions, and those would be the ones that prohibit execution, or reading, or whatever the problem is.

In addition to the basic Unix permissions, there's also an ACL (Access Control List) that may come into play. This would only have an effect after the basic permissions either granted or denied the desired access. That is, they're in addition to basic Unix permissions, not a substitute.

One can discover one's group membership by typing the id command in a Terminal window. Do this for both the admin user and non-admin user, and compare the lists.

The above is only likely to make sense if one understands how Unix permissions and ACLs work.
 
chown33 said:
It's possible that an executable or a library in either the app or the Java subsystem doesn't have the correct permission bits for non-admin users.

Admin users are members of at least one group that non-admin users are omitted from. The actual group name might vary across various OS releases, but it used to be named 'admin'.

If the group permission bits of the library or executable are correct for the admin group, and the group assigned to the file itself is the admin group, then those permissions apply when an admin user runs the app. Non-admin users aren't members of that group, so they get the "other" permissions, and those would be the ones that prohibit execution, or reading, or whatever the problem is.

In addition to the basic Unix permissions, there's also an ACL (Access Control List) that may come into play. This would only have an effect after the basic permissions either granted or denied the desired access. That is, they're in addition to basic Unix permissions, not a substitute.

One can discover one's group membership by typing the id command in a Terminal window. Do this for both the admin user and non-admin user, and compare the lists.

The above is only likely to make sense if one understands how Unix permissions and ACLs work.
Click to expand...
Are you suggesting that the original account, which was an admin user, lost that status after the upgrade?

Perhaps if, from the new admin account, the OP demoted the "normal account" down to standard user and then promoted it back to admin user, that could restore something that was lost.
 
svenmany said:
Are you suggesting that the original account, which was an admin user, lost that status after the upgrade?
Click to expand...
I think the pivotal thing is group membership and/or group permissions. We don't know what groups the original admin-user account was a member of. It's possible that the original migration or account setup omitted some group(s).

One reason I suggested using the 'id' command is that it outputs both group IDs (numbers) and group names. If there's a difference between the admin accounts regarding groups, it should be apparent by comparing the outputs. If they're all the same, then I think that decreases the likelihood the problem is related to groups.

svenmany said:
Perhaps if, from the new admin account, the OP demoted the "normal account" down to standard user and then promoted it back to admin user, that could restore something that was lost.
Click to expand...
That might be worth trying, but I'd do the 'id' command on both accounts first. If the demotion and subsequent promotion breaks something else, it will be easier to get back to the original account state if you know all the original groups.
 
I'd also be interested to see the output of that command, since the good and bad accounts are both admin accounts, assuming that "normal account" meant the one that was failing.

It's hard to definitively conclude file permissions are the cause. I'm mainly a Java developer. It's pretty standard for Java programs to write to stdout. So, starting the application in the terminal might show something, possibly the offending file if it is a permissions issue. (Or find a log file somewhere.)
 
What is the specific software package that depends on Java?

And repeating svenmany's question from post #2: How are you launching this software package? Is it from the command line, or is it a double-clicked app?
 
Sorry for the delay - got distracted with other things...

Here's the 'id' call from the terminal with the 3 accounts (milo, my main account that won't launch the app, wasp, a newly created admin account that runs the app just fine, and root login that also runs the app just fine). I launch this app by double clicking on its icon. The conspicuously weird thing for milo is the -bash error. Maybe this is it?

Main account login with admin - cannot run the app:

office:milo milo$ uid=502(milo) gid=20(staff) groups=20(staff),12(everyone),61(localaccounts),79(_appserverusr),80(admin),81(_appserveradm),98(_lpadmin),701(com.apple.sharepoint.group.1),33(_appstore),100(_lpoperator),204(_developer),250(_analyticsusers),395(com.apple.access_ftp),398(com.apple.access_screensharing),399(com.apple.access_ssh),400(com.apple.access_remote_ae)
-bash: syntax error near unexpected token `('
office:milo milo$ office:milo milo$

Newly created account with admin and the app launches just fine.

wasp@office ~ % id
uid=501(wasp) gid=20(staff) groups=20(staff),12(everyone),61(localaccounts),79(_appserverusr),80(admin),81(_appserveradm),98(_lpadmin),701(com.apple.sharepoint.group.1),33(_appstore),100(_lpoperator),204(_developer),250(_analyticsusers),395(com.apple.access_ftp),398(com.apple.access_screensharing),399(com.apple.access_ssh),400(com.apple.access_remote_ae)
wasp@office ~ %

Logged in as root and the app launches just fine

office:~ root# id
uid=0(root) gid=0(wheel) groups=0(wheel),1(daemon),2(kmem),3(sys),4(tty),5(operator),8(procview),9(procmod),12(everyone),20(staff),29(certusers),61(localaccounts),80(admin),701(com.apple.sharepoint.group.1),33(_appstore),98(_lpadmin),100(_lpoperator),204(_developer),250(_analyticsusers),395(com.apple.access_ftp),398(com.apple.access_screensharing),399(com.apple.access_ssh),400(com.apple.access_remote_ae)
office:~ root#
 
The first set of output for the milo account looks very odd indeed.

There's what looks like a shell prompt, but I don't see where the 'id' command was entered. Yet there's the output from 'id', followed by the bash error, and then a couple more prompts run together on the same line. Unless there was some kind of copy/paste error, that's some very unusual Terminal output.

I've seen wacky things like this when the shell command in Terminal has been damaged in some way. Not the shell program itself, but the Terminal setting of what to run when a Terminal window is opened. That setting used to be under:
Terminal > Preferences > Startup pane > Shells open with:

If you entered something that wasn't a proper executable's pathname, then it would cause serious disruption. I accidentally did it a couple times, and it took some fiddling with the Terminal preferences file to get things back to where a window would open and show a shell.

My guess, based on the error message about an "unexpected token '('" is that there's an open parenthesis in the command. Sorry I don't know where the Terminal preferences are stored in recent versions, but ~/Library/Preferences would be a good place to start.

If you can look into the preferences plist, it might be the Shell item. The command line to read the value is:
Code: 
defaults read com.apple.Terminal Shell

You could also try dragging the file ~/Preferences/com.apple.Terminal.plist to the Desktop (with Terminal quit), then relaunch Terminal.


I say "used to be" because I don't have a recent OS version booted right now, so I can't look at the Terminal preferences window. The above is for older OS versions, and may be radically different in modern times.


EDIT

Something else that just occurred to me is it could be a malformed shell profile file. In hindsight, this seems much more likely than a borked Terminal Preferences setting.

These files reside in your home dir, and their names start with "." so they're normall invisible to Finder.

The common profile at /etc/profile is almost certainly fine, since other accounts work.

The local files that bash then looks for are (in order):
~/.bash_profile
~/.bash_login
~/.profile

So if you tell Finder to show hidden files, look for any of those and move them to the Desktop. Then try relaunching Terminal.
 
Last edited:
I'm probably off base, but it almost looks like your prompt has a bug. Then PS1 environment variable sets the prompt. I've had prompts in the past that I had doing pretty fancy things (sometimes buggy things).

I have no idea if this issue is related to your problem starting the program. Nothing in your permissions stands out to me.
 
Cave Man said:
I migrated to Big Sur using Migration Assistant from a Time Machine volume and a software package I use that depends on Java will not launch. It gets most of the way through, then I get an alert "Unable to start Graphical User Interface" and I have to quit. What's peculiar is that if I log in as root it works just fine. Any ideas how to get around this problem? It seems it must be a permission issue of some kind.

UPDATE: So, on a whim, I created a new user account with administrator privileges (like my normal account) and the software runs just fine. So, what could be causing this problem?
Click to expand...
Which JAVA release are you running on?
;JOOP!
 
Ugh, there was a goof-up on my copy paste for my main account (sorry about that!). I should have double-checked it. Here is the correct one.

office:milo milo$ id
uid=502(milo) gid=20(staff) groups=20(staff),12(everyone),61(localaccounts),79(_appserverusr),80(admin),81(_appserveradm),98(_lpadmin),701(com.apple.sharepoint.group.1),33(_appstore),100(_lpoperator),204(_developer),250(_analyticsusers),395(com.apple.access_ftp),398(com.apple.access_screensharing),399(com.apple.access_ssh),400(com.apple.access_remote_ae)

It looks like milo (not launching) and wasp (launching) are identical (and root is different).
 
Cave Man said:
Ugh, there was a goof-up on my copy paste for my main account (sorry about that!). I should have double-checked it. Here is the correct one.

office:milo milo$ id
uid=502(milo) gid=20(staff) groups=20(staff),12(everyone),61(localaccounts),79(_appserverusr),80(admin),81(_appserveradm),98(_lpadmin),701(com.apple.sharepoint.group.1),33(_appstore),100(_lpoperator),204(_developer),250(_analyticsusers),395(com.apple.access_ftp),398(com.apple.access_screensharing),399(com.apple.access_ssh),400(com.apple.access_remote_ae)

It looks like milo (not launching) and wasp (launching) are identical (and root is different).
Click to expand...
I think that rules out a group permissions problem.

I still recommend checking the bash profile files on the 'milo' account. As I recall, a new user account won't have any profile files, so it's conceivable that something in a bash profile is causing a Java or app component to fail, but isn't affecting the login shell.

If there are no bash profiles on 'milo', then compare any other hidden files or folders on 'milo' that don't exist on 'wasp'.
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back