After doing sudo su - (to give myself root privileges) when I tried editing a file using gedit info.txt it would show me the following error message:
root@arvind-Inspiron-1440:~# gedit info.txt No protocol specified (gedit:4700): Gtk-WARNING **: cannot open display: :0.0
After doing some search I found the following reason:
X authentication is based on cookies -- secret little pieces of random data that only you and the X server know... So, you need to let the other user in on what your cookie is. One way to do this is as follows:
Before you issue the su or sudo (but after having ssh'ed into the remote system if you are using ssh), request the cookie for the current DISPLAY that's connecting to your X server:
As suggested I followed the steps given below and i was able to find a way to get rid of xauth error messages.
First of all, to get the current COOKIE information, I do xauth list $DISPLAY:
arvind@arvind-Inspiron-1440:~$ xauth list $DISPLAY
Which gives me the following value:
arvind-Inspiron-1440/unix:0 MIT-MAGIC-COOKIE-1 bfa2e2b478a6ef3c362301170214c04e
Now, I promote myself to root by doing sudo su - (and entering the password). It results in switching the current user. Here’s the command line with result to give myself the root privileges:
arvind@arvind-Inspiron-1440:~$ sudo su -
[sudo] password for arvind:
root@arvind-Inspiron-1440:~#
Next, I added xauth add to the value returned by xauth list $DISPLAY (given above) and ran it in the console as:
root@arvind-Inspiron-1440:~# xauth add arvind-Inspiron-1440/unix:0 MIT-MAGIC-COOKIE-1 bfa2e2b478a6ef3c362301170214c04e
Now I can edit any file within my system using my gedit or jedit editor in console.
I guest there must be a permanent solution to it but until I get one it works just fine for me.
Here the more permanent solution:
With the default X authentication mechanism, an X client needs to have access to a valid X session cookie (which is, essentially, a shared secret between the X server and its clients).
When a user switches to a different user using the su command, X session cookies are not transferred and thus the user cannot start X applications under the user id to which he or she switched.
Solution to the authentication credentials problem: sux
Instead of su, use sux to switch user id. Like su, sux switches to a different user id. Unlike su, it ensures that the id being assumed is given access to the X session cookie so that X applications can be started.
Thank u very muchhh..
Hopefully get solutions for other problems as well..:P
Thanks a lot. i had been scratching my head around this problem.
Great, thanks!