Cannot use gedit on multiple remote machines using ssh

Question

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.

Solution 1

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

Solution 2

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 in the server info (use ssh:// or sftp:// for ssh connections).

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.

Solution 3

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.

Comments

[hytromo]

Did you try adding DISPLAY=:0 prior to the gedit command? Something like DISPLAY=:0 gedit

[StephenTG]

@hakermania I don't get errors when I do that, but I'm not seeing the gedit window...

[amc]

Why do you need to use gedit instead of a terminal-based text editor like nano or vi?

[StephenTG]

@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.

[amc]

Alternatively, have you tried using nautilus to connect via ssh and browsing files that way? Using gedit on your local machine instead of xforwarding?

[StephenTG]

@amc If you mean opening nautilus through ssh, then yes, and it seems to work fine, although it does complain at me. Otherwise I'm not exactly sure what you're suggesting

[amc]

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.

[StephenTG]

@amc didn't know about that. That works, but will I be able to open files as root? I've been doing a lot of editing of files in etc, and though I think everything's set up the way I want, I might need to do some more in the future

[StephenTG]

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]

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]

+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

[IljaBek]

worked for me marvelously. (together with export NO_AT_BRIDGE=1$)

[Chux Uzoeto]

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.

[Nicolas]

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.