6

After setting up the last of my 5 remote machines, I decided to test that the network was working well by connecting to each and opening gedit.

To my dismay, when I tried to open gedit on the second machine, I was greeted with:

** (gedit:1862): WARNING **; Could not connect: Connection refused

** (gedit:1862): WARNING **; Could not connect to session bus

Closing gedit didn't help, but when I closed my ssh connection to the first remote machine, I was able to open gedit on the second. I decided to check if this was a problem with all X programs, but I was able to open xeyes on multiple remote machines.

My question is, why does remotely opening gedit on one machine prevent me from opening it on another until the first ssh session is closed? And is there a way to fix this or a workaround? I don't need to have multiple gedits open at once, but I'd least like to be able to not have to close the connection to one of the machines before I can open it on another.

My ssh_config is set up with 'ForwardX11' and 'ForwardX11Trusted' both set to yes, in case this is pertinent.

Update: I decided to try a few more programs, and found that while I can have nautilus open through ssh on multiple machines, I get a number of the connection refused warnings before it opens.

9
  • Did you try adding DISPLAY=:0 prior to the gedit command? Something like DISPLAY=:0 gedit
    – hytromo
    Aug 21, 2013 at 17:49
  • @hakermania I don't get errors when I do that, but I'm not seeing the gedit window...
    – StephenTG
    Aug 21, 2013 at 17:52
  • Why do you need to use gedit instead of a terminal-based text editor like nano or vi?
    – amc
    Aug 23, 2013 at 15:59
  • @amc I've tried using vi, but I'm having issues getting the hang of it. Haven't tried nano. As is, it's easier for me to close connections and only edit files on one machine at a time than to do anything remotely involved in vi. Probably something I should pick up eventually, but at the moment it doesn't really seem worth the effort.
    – StephenTG
    Aug 23, 2013 at 16:01
  • 1
    I mean using nautilus on local machine: from the menu in the top panel, select connect to server, and enter in the server info. Once connected you can bookmark the location using ctrl-d. Then double click the file you want to edit in gedit and go from there.
    – amc
    Aug 23, 2013 at 16:09

3 Answers 3

5

export $(dbus-launch) on the remote machine solved this problem for me.

2
  • worked for me marvelously. (together with export NO_AT_BRIDGE=1$)
    – IljaBek
    Feb 21, 2014 at 17:37
  • Thx this worked! Does anyone know the background story? Why is this needed now, whereas it wasn't necessary before? Is there a way to fix this permanently? Side note: as this affects all gui applications, it may be not that important for gedit, but for applications involving far more complicated cli equivalents - e. g. palimpsest or gparted - this is kind of essential.
    – Nicolas
    Nov 27, 2014 at 19:21
1

This is a problem with whatever is acting as the X Display manager (or X server) on the PC/laptop from where you are testing gedit. So, what operating system and X server software are you using?

Typically, the process for displaying a remote X application on your local PC would involve:

  • X server on the local PC, configured to authorize remote connections
  • SSH tunnel to the remote system
  • setting an environment variable DISPLAY, to point to your local PC (either by name or IP address)

If you are in windows, Xming works well as an X server with putty or ssh client from ssh.com .. It would allow you to manage your local X displays, and authorize remote apps to display on your local system.

3
  • All computers involved are running Ubuntu 12.04, all PCs, not laptops. How would I go about checking what particular X server software they're running?
    – StephenTG
    Aug 23, 2013 at 15:56
  • Also, as a note, since based on your answer I might not have been clear in my question: I can get gedit to open on each individual remote machine through ssh, the problem only occurs if I try to open it on one machine when I still have an active ssh connection to another that either has gedit open or previously had it open.
    – StephenTG
    Aug 23, 2013 at 15:59
  • Sorry, just seen this. I think this is probably a problem with your DBUS_SESSION. Perhaps it is not being forwarded during the ssh forwarding (the same way your DISPLAY variable is forwarded). Or perhaps the user does not own all the files under .dbus. Try and do a ls -ltr .dbus/session-bus OR check that all files under .dbus are owned by the user .. say .. find .dbus ! -user <username-that-runs-gedit> .. You may have to do a chmod -R <username>.<groupname> .dbus. Apr 25, 2014 at 15:41
1

1) Use a commandline text editor

ssh into the remote machine via the terminal and use nano or vi to open the text file and edit.

I find nano to be more newbie-friendly, in part because it shows you the key combinations for various actions directly in your terminal window.

To open a file using nano: nano filename.txt or sudo nano filename.txt (if you need root privileges)


2) Use nautilus/gedit on local machine

Open a nautilus file browser window and select "connect to server" from the menu in the top panel.

enter image description here

Enter in the server info (use ssh:// or sftp:// for ssh connections).

enter image description here

Once connected you can bookmark the location using ctrl+d. Then double click the file you want to edit in gedit and go from there.

One drawback: unless you ssh in as root, opening files that require root privileges is less straight forward using this approach. One thing you can do, if you have nautilus-open-terminal installed, is to right click in the nautilus window where the file is located and select "open in remote terminal", then use sudo nano filename.txt as above.

1
  • +1 for being an entirely helpful workaround, though I'll hold out a bit longer to see if there's a solution (or explanation why there can't be a solution) for what I was trying to accomplish before I accept it
    – StephenTG
    Aug 23, 2013 at 16:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .