Sudo gedit command not found mint driver#
I had this error "No protocol specified" when I started an instance of Selenium 3.3.1 from an upstart script and then used the Chrome driver in Selenium. Xauthority file with a new cookie and also restart the server with that same cookie, of course. Just restarting X should regenerate your.
Sudo gedit command not found mint how to#
The only place where you can get it back from is the memory (RAM) of the Xorg process but I am too lazy to figure out how to recover that. In this case the cookie has completely vanished thus. Trap "rm -f '$xserverauthfile'" HUP INT QUIT ILL TRAP KILL BUS TERMĪdding the random cookie to the users.
Xserverauthfile=`mktemp -p /tmp serverauth.XXXXXXXXXX` See /usr/bin/startx script for how this works: mcookie=`/usr/bin/mcookie` Xauthority should be size 51 bytes and you can connect to the X server (again). Replace 'c0eaf749aa252101a0f57d5087089db7' with what was returned by the list command for you. Xauthority file (as user who needs to login again): Find the authority file that the X server is using at the moment: Recreate it, but empty (this is needed for a lot of commands):Īt this point you'll get the No protocol specified error, even if you got Invalid MIT-MAGIC-COOKIE-1 before. In the above command, replace /root/.Xauthority with the correct XAUTHORITY file for your case of course. Mv /root/.Xauthority /root/.Xauthority.bak Xauthority file then you don't have to worry about the XAUTHORITY environment variable actually (actually, I wouldn't know when it wouldn't, except if you want to manipulate a non-standard place of that file). This will show the 'Authority file' that will be used (/root/.Xauthority by default, for root, or something like /home/theuser/.Xauthority). For example, try: sudo bash -c 'echo "$XAUTHORITY"' to see what XAUTHORITY really is after you run your sudo (if it disappears you might need to add something to your sudoers file, see elsewhere).Įventually, run the following command as the user that you want to get access with, on the server: To test if that is the case you could run 'echo $XAUTHORITY' in the same way you run your commands, but make sure you aren't expanding the environment variables before you run those commands. The following environment variables need to be preserved: DISPLAY and XAUTHORITY. There might be several ways to run the xauth commands, for example, you might be using 'sudo', but that might lose or change environment variables. Lets assume you are already running your commands on the server (where X runs), otherwise get that to work first and then use 'ssh -X from the client afterwards ). Suppose you want to brute force get yourself a connection with X. That command extracts the magic cookie ( xauth list) from your main user and adds it ( xauth add) to where the other user can get it. You may also need to unset XAUTHORITY in that shell too. Try this, running as your original user, to copy the X11 cookie to the other account: su -c "unset XAUTHORITY xauth add $(xauth list)" The other system user does not have access to this magic cookie because the permissions are set so that it is only accessible to the user who started the desktop environment (which is as it should be). Applications need a "magic cookie" (secret token) in order to talk to the X11 server so that other processes on the system running under other users cannot intrude on your display, create windows, and snoop your keystrokes. The error message No protocol specified sounds like an application-specific error message, and an unhelpful one at that, but I am going to guess that the error is that the application is unable to contact your X11 display because it does not have permission to do so because it's running as a different user. 500 is just fine as a UID, and that UID doesn't make it a 'non-login' user except in the eyes of the default settings of some few display managers. The problem is not occurring because of the UID of the user.
0 kommentar(er)
