Cannot connect to X server :0.0 as superuser

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
7
down vote

favorite
3












When I am online, I get following error and the tool does not start:



[root@dhcppc9 lin64]# ./ise
No protocol specified
_pn: cannot connect to X server :0.0


But everything is OK when I am not a superuser. Why that?



Edit



[root@dhcppc9 lin64]# export $(dbus-launch)
No protocol specified


any suggestion?



Also



[root@dhcppc9 lin64]# xhost [+]
No protocol specified
xhost: unable to open display ":0.0"









share|improve this question























  • This is a classic. You may do export $(dbus-launch) or use xhost [+] to be able to launch programs using X and your superuser account.
    – uprego
    Jan 31 '14 at 9:23










  • Did both , see the edit above
    – msz
    Jan 31 '14 at 9:28










  • It may be $ xhost to see the current access and $ xhost + to enable access from any host. You often do this from a virtual terminal you know for sure that can spawn programs using X.
    – uprego
    Jan 31 '14 at 9:42










  • @galegosimpatico: why would launching a dbus server solve this issue?
    – Bananguin
    Jan 31 '14 at 9:47










  • When you are not superuser, what does echo $DISPLAY show? Which user does the xserver process, you want to use, belong to? (you can find out the latter by using for example ps faux)
    – Bananguin
    Jan 31 '14 at 9:49















up vote
7
down vote

favorite
3












When I am online, I get following error and the tool does not start:



[root@dhcppc9 lin64]# ./ise
No protocol specified
_pn: cannot connect to X server :0.0


But everything is OK when I am not a superuser. Why that?



Edit



[root@dhcppc9 lin64]# export $(dbus-launch)
No protocol specified


any suggestion?



Also



[root@dhcppc9 lin64]# xhost [+]
No protocol specified
xhost: unable to open display ":0.0"









share|improve this question























  • This is a classic. You may do export $(dbus-launch) or use xhost [+] to be able to launch programs using X and your superuser account.
    – uprego
    Jan 31 '14 at 9:23










  • Did both , see the edit above
    – msz
    Jan 31 '14 at 9:28










  • It may be $ xhost to see the current access and $ xhost + to enable access from any host. You often do this from a virtual terminal you know for sure that can spawn programs using X.
    – uprego
    Jan 31 '14 at 9:42










  • @galegosimpatico: why would launching a dbus server solve this issue?
    – Bananguin
    Jan 31 '14 at 9:47










  • When you are not superuser, what does echo $DISPLAY show? Which user does the xserver process, you want to use, belong to? (you can find out the latter by using for example ps faux)
    – Bananguin
    Jan 31 '14 at 9:49













up vote
7
down vote

favorite
3









up vote
7
down vote

favorite
3






3





When I am online, I get following error and the tool does not start:



[root@dhcppc9 lin64]# ./ise
No protocol specified
_pn: cannot connect to X server :0.0


But everything is OK when I am not a superuser. Why that?



Edit



[root@dhcppc9 lin64]# export $(dbus-launch)
No protocol specified


any suggestion?



Also



[root@dhcppc9 lin64]# xhost [+]
No protocol specified
xhost: unable to open display ":0.0"









share|improve this question















When I am online, I get following error and the tool does not start:



[root@dhcppc9 lin64]# ./ise
No protocol specified
_pn: cannot connect to X server :0.0


But everything is OK when I am not a superuser. Why that?



Edit



[root@dhcppc9 lin64]# export $(dbus-launch)
No protocol specified


any suggestion?



Also



[root@dhcppc9 lin64]# xhost [+]
No protocol specified
xhost: unable to open display ":0.0"






x11 su xauth






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jan 31 '14 at 22:48









Gilles

515k12210241553




515k12210241553










asked Jan 31 '14 at 9:21









msz

56229




56229











  • This is a classic. You may do export $(dbus-launch) or use xhost [+] to be able to launch programs using X and your superuser account.
    – uprego
    Jan 31 '14 at 9:23










  • Did both , see the edit above
    – msz
    Jan 31 '14 at 9:28










  • It may be $ xhost to see the current access and $ xhost + to enable access from any host. You often do this from a virtual terminal you know for sure that can spawn programs using X.
    – uprego
    Jan 31 '14 at 9:42










  • @galegosimpatico: why would launching a dbus server solve this issue?
    – Bananguin
    Jan 31 '14 at 9:47










  • When you are not superuser, what does echo $DISPLAY show? Which user does the xserver process, you want to use, belong to? (you can find out the latter by using for example ps faux)
    – Bananguin
    Jan 31 '14 at 9:49

















  • This is a classic. You may do export $(dbus-launch) or use xhost [+] to be able to launch programs using X and your superuser account.
    – uprego
    Jan 31 '14 at 9:23










  • Did both , see the edit above
    – msz
    Jan 31 '14 at 9:28










  • It may be $ xhost to see the current access and $ xhost + to enable access from any host. You often do this from a virtual terminal you know for sure that can spawn programs using X.
    – uprego
    Jan 31 '14 at 9:42










  • @galegosimpatico: why would launching a dbus server solve this issue?
    – Bananguin
    Jan 31 '14 at 9:47










  • When you are not superuser, what does echo $DISPLAY show? Which user does the xserver process, you want to use, belong to? (you can find out the latter by using for example ps faux)
    – Bananguin
    Jan 31 '14 at 9:49
















This is a classic. You may do export $(dbus-launch) or use xhost [+] to be able to launch programs using X and your superuser account.
– uprego
Jan 31 '14 at 9:23




This is a classic. You may do export $(dbus-launch) or use xhost [+] to be able to launch programs using X and your superuser account.
– uprego
Jan 31 '14 at 9:23












Did both , see the edit above
– msz
Jan 31 '14 at 9:28




Did both , see the edit above
– msz
Jan 31 '14 at 9:28












It may be $ xhost to see the current access and $ xhost + to enable access from any host. You often do this from a virtual terminal you know for sure that can spawn programs using X.
– uprego
Jan 31 '14 at 9:42




It may be $ xhost to see the current access and $ xhost + to enable access from any host. You often do this from a virtual terminal you know for sure that can spawn programs using X.
– uprego
Jan 31 '14 at 9:42












@galegosimpatico: why would launching a dbus server solve this issue?
– Bananguin
Jan 31 '14 at 9:47




@galegosimpatico: why would launching a dbus server solve this issue?
– Bananguin
Jan 31 '14 at 9:47












When you are not superuser, what does echo $DISPLAY show? Which user does the xserver process, you want to use, belong to? (you can find out the latter by using for example ps faux)
– Bananguin
Jan 31 '14 at 9:49





When you are not superuser, what does echo $DISPLAY show? Which user does the xserver process, you want to use, belong to? (you can find out the latter by using for example ps faux)
– Bananguin
Jan 31 '14 at 9:49











4 Answers
4






active

oldest

votes

















up vote
10
down vote













An X program needs two pieces of information in order to connect to an X display.



  • It needs the address of the display, which is typically :0 when you're logged in locally or :10, :11, etc. when you're logged in remotely (but the number can change depending on how many X connections are active). The address of the display is normally indicated in the DISPLAY environment variable.


  • It needs the password for the display. X display passwords are called magic cookies. Magic cookies are not specified directly: they are always stored in X authority files, which are a collection of records of the form “display :42 has cookie 123456”. The X authority file is normally indicated in the XAUTHORITY environment variable. If $XAUTHORITY is not set, programs use ~/.Xauthority.


See Open a window on a remote X display (why "Cannot open display")? for more details.



In your case, DISPLAY is set but programs evidently cannot find the cookie file. Check the value of XAUTHORITY in your session and under su.



If XAUTHORITY is not set in your session and su sets the HOME environment variable to root's home directory, then you need to set XAUTHORITY to /home/msz/.Xauthority where /home/msz is your home directory.



If su removes XAUTHORITY from the environment, either put it back, or configure su not to do this.



If your home directory is on some filesystems like NFS, root may not be able to read it directly. In that case, you can copy the .Xauthority file to a different location on a non-NFS filesystem:



XAUTHORITY_COPY=$(umask 077; mktemp)
cat "$XAUTHORITY:-~/.Xauthority" "$XAUTHORITY_COPY"
XAUTHORITY="$XAUTHORITY_COPY" su
rm "$XAUTHORITY_COPY"
unset XAUTHORITY_COPY





share|improve this answer


















  • 1




    I created a symbolic link and it worked as well. Here it is: ln -s /home/otheruser/.Xauthority ~
    – Can Geliş
    Feb 3 '15 at 8:58










  • XAUTHORITY for me was set as a file that no longer existed:
    – pbhj
    Jan 11 '16 at 13:28

















up vote
2
down vote













You are running xhost as root !



run xhost as the normal user xhost + , then become root then try again.



btw as others have pointed out xhost + permits any user from any host






share|improve this answer






















  • Many modern systems are set up so that xhost does not work. If it does, then at least run xhost +localhost, not xhost +!
    – Gilles
    Jan 31 '14 at 22:48










  • Understand, that's a good point. Thanks for your advice.
    – X Tian
    Feb 1 '14 at 2:04

















up vote
0
down vote













XAUTHORITY for me was set as a file that no longer existed:



$ echo $XAUTHORITY



/tmp/xauth-1000-_0



So I did



unset XAUTHORITY



and was then able to connect to my app as root using kdesudo (in this case kdesudo bleachbit)






share|improve this answer



























    up vote
    0
    down vote













    Run as normal user



    xhost + localhost


    then enable super user by



    sudo su 


    finally go to server example



    cd /usr/local/Ampps


    finally run
    ./Ampps



    thank me in 2020





    share








    New contributor




    Dev Mash E is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.

















      Your Answer







      StackExchange.ready(function()
      var channelOptions =
      tags: "".split(" "),
      id: "106"
      ;
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function()
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled)
      StackExchange.using("snippets", function()
      createEditor();
      );

      else
      createEditor();

      );

      function createEditor()
      StackExchange.prepareEditor(
      heartbeatType: 'answer',
      convertImagesToLinks: false,
      noModals: false,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: null,
      bindNavPrevention: true,
      postfix: "",
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      );



      );













       

      draft saved


      draft discarded


















      StackExchange.ready(
      function ()
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f111831%2fcannot-connect-to-x-server-0-0-as-superuser%23new-answer', 'question_page');

      );

      Post as a guest






























      4 Answers
      4






      active

      oldest

      votes








      4 Answers
      4






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes








      up vote
      10
      down vote













      An X program needs two pieces of information in order to connect to an X display.



      • It needs the address of the display, which is typically :0 when you're logged in locally or :10, :11, etc. when you're logged in remotely (but the number can change depending on how many X connections are active). The address of the display is normally indicated in the DISPLAY environment variable.


      • It needs the password for the display. X display passwords are called magic cookies. Magic cookies are not specified directly: they are always stored in X authority files, which are a collection of records of the form “display :42 has cookie 123456”. The X authority file is normally indicated in the XAUTHORITY environment variable. If $XAUTHORITY is not set, programs use ~/.Xauthority.


      See Open a window on a remote X display (why "Cannot open display")? for more details.



      In your case, DISPLAY is set but programs evidently cannot find the cookie file. Check the value of XAUTHORITY in your session and under su.



      If XAUTHORITY is not set in your session and su sets the HOME environment variable to root's home directory, then you need to set XAUTHORITY to /home/msz/.Xauthority where /home/msz is your home directory.



      If su removes XAUTHORITY from the environment, either put it back, or configure su not to do this.



      If your home directory is on some filesystems like NFS, root may not be able to read it directly. In that case, you can copy the .Xauthority file to a different location on a non-NFS filesystem:



      XAUTHORITY_COPY=$(umask 077; mktemp)
      cat "$XAUTHORITY:-~/.Xauthority" "$XAUTHORITY_COPY"
      XAUTHORITY="$XAUTHORITY_COPY" su
      rm "$XAUTHORITY_COPY"
      unset XAUTHORITY_COPY





      share|improve this answer


















      • 1




        I created a symbolic link and it worked as well. Here it is: ln -s /home/otheruser/.Xauthority ~
        – Can Geliş
        Feb 3 '15 at 8:58










      • XAUTHORITY for me was set as a file that no longer existed:
        – pbhj
        Jan 11 '16 at 13:28














      up vote
      10
      down vote













      An X program needs two pieces of information in order to connect to an X display.



      • It needs the address of the display, which is typically :0 when you're logged in locally or :10, :11, etc. when you're logged in remotely (but the number can change depending on how many X connections are active). The address of the display is normally indicated in the DISPLAY environment variable.


      • It needs the password for the display. X display passwords are called magic cookies. Magic cookies are not specified directly: they are always stored in X authority files, which are a collection of records of the form “display :42 has cookie 123456”. The X authority file is normally indicated in the XAUTHORITY environment variable. If $XAUTHORITY is not set, programs use ~/.Xauthority.


      See Open a window on a remote X display (why "Cannot open display")? for more details.



      In your case, DISPLAY is set but programs evidently cannot find the cookie file. Check the value of XAUTHORITY in your session and under su.



      If XAUTHORITY is not set in your session and su sets the HOME environment variable to root's home directory, then you need to set XAUTHORITY to /home/msz/.Xauthority where /home/msz is your home directory.



      If su removes XAUTHORITY from the environment, either put it back, or configure su not to do this.



      If your home directory is on some filesystems like NFS, root may not be able to read it directly. In that case, you can copy the .Xauthority file to a different location on a non-NFS filesystem:



      XAUTHORITY_COPY=$(umask 077; mktemp)
      cat "$XAUTHORITY:-~/.Xauthority" "$XAUTHORITY_COPY"
      XAUTHORITY="$XAUTHORITY_COPY" su
      rm "$XAUTHORITY_COPY"
      unset XAUTHORITY_COPY





      share|improve this answer


















      • 1




        I created a symbolic link and it worked as well. Here it is: ln -s /home/otheruser/.Xauthority ~
        – Can Geliş
        Feb 3 '15 at 8:58










      • XAUTHORITY for me was set as a file that no longer existed:
        – pbhj
        Jan 11 '16 at 13:28












      up vote
      10
      down vote










      up vote
      10
      down vote









      An X program needs two pieces of information in order to connect to an X display.



      • It needs the address of the display, which is typically :0 when you're logged in locally or :10, :11, etc. when you're logged in remotely (but the number can change depending on how many X connections are active). The address of the display is normally indicated in the DISPLAY environment variable.


      • It needs the password for the display. X display passwords are called magic cookies. Magic cookies are not specified directly: they are always stored in X authority files, which are a collection of records of the form “display :42 has cookie 123456”. The X authority file is normally indicated in the XAUTHORITY environment variable. If $XAUTHORITY is not set, programs use ~/.Xauthority.


      See Open a window on a remote X display (why "Cannot open display")? for more details.



      In your case, DISPLAY is set but programs evidently cannot find the cookie file. Check the value of XAUTHORITY in your session and under su.



      If XAUTHORITY is not set in your session and su sets the HOME environment variable to root's home directory, then you need to set XAUTHORITY to /home/msz/.Xauthority where /home/msz is your home directory.



      If su removes XAUTHORITY from the environment, either put it back, or configure su not to do this.



      If your home directory is on some filesystems like NFS, root may not be able to read it directly. In that case, you can copy the .Xauthority file to a different location on a non-NFS filesystem:



      XAUTHORITY_COPY=$(umask 077; mktemp)
      cat "$XAUTHORITY:-~/.Xauthority" "$XAUTHORITY_COPY"
      XAUTHORITY="$XAUTHORITY_COPY" su
      rm "$XAUTHORITY_COPY"
      unset XAUTHORITY_COPY





      share|improve this answer














      An X program needs two pieces of information in order to connect to an X display.



      • It needs the address of the display, which is typically :0 when you're logged in locally or :10, :11, etc. when you're logged in remotely (but the number can change depending on how many X connections are active). The address of the display is normally indicated in the DISPLAY environment variable.


      • It needs the password for the display. X display passwords are called magic cookies. Magic cookies are not specified directly: they are always stored in X authority files, which are a collection of records of the form “display :42 has cookie 123456”. The X authority file is normally indicated in the XAUTHORITY environment variable. If $XAUTHORITY is not set, programs use ~/.Xauthority.


      See Open a window on a remote X display (why "Cannot open display")? for more details.



      In your case, DISPLAY is set but programs evidently cannot find the cookie file. Check the value of XAUTHORITY in your session and under su.



      If XAUTHORITY is not set in your session and su sets the HOME environment variable to root's home directory, then you need to set XAUTHORITY to /home/msz/.Xauthority where /home/msz is your home directory.



      If su removes XAUTHORITY from the environment, either put it back, or configure su not to do this.



      If your home directory is on some filesystems like NFS, root may not be able to read it directly. In that case, you can copy the .Xauthority file to a different location on a non-NFS filesystem:



      XAUTHORITY_COPY=$(umask 077; mktemp)
      cat "$XAUTHORITY:-~/.Xauthority" "$XAUTHORITY_COPY"
      XAUTHORITY="$XAUTHORITY_COPY" su
      rm "$XAUTHORITY_COPY"
      unset XAUTHORITY_COPY






      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited Apr 13 '17 at 12:37









      Community♦

      1




      1










      answered Jan 31 '14 at 22:47









      Gilles

      515k12210241553




      515k12210241553







      • 1




        I created a symbolic link and it worked as well. Here it is: ln -s /home/otheruser/.Xauthority ~
        – Can Geliş
        Feb 3 '15 at 8:58










      • XAUTHORITY for me was set as a file that no longer existed:
        – pbhj
        Jan 11 '16 at 13:28












      • 1




        I created a symbolic link and it worked as well. Here it is: ln -s /home/otheruser/.Xauthority ~
        – Can Geliş
        Feb 3 '15 at 8:58










      • XAUTHORITY for me was set as a file that no longer existed:
        – pbhj
        Jan 11 '16 at 13:28







      1




      1




      I created a symbolic link and it worked as well. Here it is: ln -s /home/otheruser/.Xauthority ~
      – Can Geliş
      Feb 3 '15 at 8:58




      I created a symbolic link and it worked as well. Here it is: ln -s /home/otheruser/.Xauthority ~
      – Can Geliş
      Feb 3 '15 at 8:58












      XAUTHORITY for me was set as a file that no longer existed:
      – pbhj
      Jan 11 '16 at 13:28




      XAUTHORITY for me was set as a file that no longer existed:
      – pbhj
      Jan 11 '16 at 13:28












      up vote
      2
      down vote













      You are running xhost as root !



      run xhost as the normal user xhost + , then become root then try again.



      btw as others have pointed out xhost + permits any user from any host






      share|improve this answer






















      • Many modern systems are set up so that xhost does not work. If it does, then at least run xhost +localhost, not xhost +!
        – Gilles
        Jan 31 '14 at 22:48










      • Understand, that's a good point. Thanks for your advice.
        – X Tian
        Feb 1 '14 at 2:04














      up vote
      2
      down vote













      You are running xhost as root !



      run xhost as the normal user xhost + , then become root then try again.



      btw as others have pointed out xhost + permits any user from any host






      share|improve this answer






















      • Many modern systems are set up so that xhost does not work. If it does, then at least run xhost +localhost, not xhost +!
        – Gilles
        Jan 31 '14 at 22:48










      • Understand, that's a good point. Thanks for your advice.
        – X Tian
        Feb 1 '14 at 2:04












      up vote
      2
      down vote










      up vote
      2
      down vote









      You are running xhost as root !



      run xhost as the normal user xhost + , then become root then try again.



      btw as others have pointed out xhost + permits any user from any host






      share|improve this answer














      You are running xhost as root !



      run xhost as the normal user xhost + , then become root then try again.



      btw as others have pointed out xhost + permits any user from any host







      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited Jan 31 '14 at 12:56

























      answered Jan 31 '14 at 12:48









      X Tian

      7,45111936




      7,45111936











      • Many modern systems are set up so that xhost does not work. If it does, then at least run xhost +localhost, not xhost +!
        – Gilles
        Jan 31 '14 at 22:48










      • Understand, that's a good point. Thanks for your advice.
        – X Tian
        Feb 1 '14 at 2:04
















      • Many modern systems are set up so that xhost does not work. If it does, then at least run xhost +localhost, not xhost +!
        – Gilles
        Jan 31 '14 at 22:48










      • Understand, that's a good point. Thanks for your advice.
        – X Tian
        Feb 1 '14 at 2:04















      Many modern systems are set up so that xhost does not work. If it does, then at least run xhost +localhost, not xhost +!
      – Gilles
      Jan 31 '14 at 22:48




      Many modern systems are set up so that xhost does not work. If it does, then at least run xhost +localhost, not xhost +!
      – Gilles
      Jan 31 '14 at 22:48












      Understand, that's a good point. Thanks for your advice.
      – X Tian
      Feb 1 '14 at 2:04




      Understand, that's a good point. Thanks for your advice.
      – X Tian
      Feb 1 '14 at 2:04










      up vote
      0
      down vote













      XAUTHORITY for me was set as a file that no longer existed:



      $ echo $XAUTHORITY



      /tmp/xauth-1000-_0



      So I did



      unset XAUTHORITY



      and was then able to connect to my app as root using kdesudo (in this case kdesudo bleachbit)






      share|improve this answer
























        up vote
        0
        down vote













        XAUTHORITY for me was set as a file that no longer existed:



        $ echo $XAUTHORITY



        /tmp/xauth-1000-_0



        So I did



        unset XAUTHORITY



        and was then able to connect to my app as root using kdesudo (in this case kdesudo bleachbit)






        share|improve this answer






















          up vote
          0
          down vote










          up vote
          0
          down vote









          XAUTHORITY for me was set as a file that no longer existed:



          $ echo $XAUTHORITY



          /tmp/xauth-1000-_0



          So I did



          unset XAUTHORITY



          and was then able to connect to my app as root using kdesudo (in this case kdesudo bleachbit)






          share|improve this answer












          XAUTHORITY for me was set as a file that no longer existed:



          $ echo $XAUTHORITY



          /tmp/xauth-1000-_0



          So I did



          unset XAUTHORITY



          and was then able to connect to my app as root using kdesudo (in this case kdesudo bleachbit)







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Jan 11 '16 at 13:30









          pbhj

          19818




          19818




















              up vote
              0
              down vote













              Run as normal user



              xhost + localhost


              then enable super user by



              sudo su 


              finally go to server example



              cd /usr/local/Ampps


              finally run
              ./Ampps



              thank me in 2020





              share








              New contributor




              Dev Mash E is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
              Check out our Code of Conduct.





















                up vote
                0
                down vote













                Run as normal user



                xhost + localhost


                then enable super user by



                sudo su 


                finally go to server example



                cd /usr/local/Ampps


                finally run
                ./Ampps



                thank me in 2020





                share








                New contributor




                Dev Mash E is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.



















                  up vote
                  0
                  down vote










                  up vote
                  0
                  down vote









                  Run as normal user



                  xhost + localhost


                  then enable super user by



                  sudo su 


                  finally go to server example



                  cd /usr/local/Ampps


                  finally run
                  ./Ampps



                  thank me in 2020





                  share








                  New contributor




                  Dev Mash E is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.









                  Run as normal user



                  xhost + localhost


                  then enable super user by



                  sudo su 


                  finally go to server example



                  cd /usr/local/Ampps


                  finally run
                  ./Ampps



                  thank me in 2020






                  share








                  New contributor




                  Dev Mash E is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.








                  share


                  share






                  New contributor




                  Dev Mash E is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.









                  answered 2 mins ago









                  Dev Mash E

                  1




                  1




                  New contributor




                  Dev Mash E is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.





                  New contributor





                  Dev Mash E is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.






                  Dev Mash E is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.



























                       

                      draft saved


                      draft discarded















































                       


                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function ()
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f111831%2fcannot-connect-to-x-server-0-0-as-superuser%23new-answer', 'question_page');

                      );

                      Post as a guest













































































                      Popular posts from this blog

                      How to check contact read email or not when send email to Individual?

                      Bahrain

                      Postfix configuration issue with fips on centos 7; mailgun relay