I'm trying to access a remote davs server with emacs through tramp. I use the syntax
/davs:username#servername.fr: TAB
With ftp, this would ask for a password, connect to the server and open a completion list. But with davs Emacs gives the error Package tramp-gvfs' not supported`. Checking the messages buffer the error is linked to "completion--some" so I'm not sure it has to do with tramp itself. In the messages buffer I also see
Opening connection for davs using scpc... \
Tramp: Opening connection for davs using scpc...done
byte-code: Process died
I tried to specify the port number by adding #2078 after servername.fr but it didn't make any difference.
The connection works fine with my file managers (Nautilus and Thunar) so I suppose gvfs is set up properly on my system. Where else should I look?
You get this error message if Emacs is not compiled with DBus support, if it cannot connect to the session bus, or if neither gvfs-fuse-daemon nor gvfsd-fuse is running. (See the definition of tramp-gvfs-enabled.)
I seem to remember that I had to start gvfs-fuse-daemon manually, but I'm not sure exactly what I did to get it work; this was a long time ago on a different computer... Hopefully someone else can come up with a more complete answer.
Related
I find that if I leave my VS Code Remote SSH connection open it disconnects automatically after a certain amount of time. Following automatic disconnection I find the Remote SSH then fails: when I try to log in again I get repeated requests for my remote password and every time I enter my password I just get another password prompt.
My current workaround is to go to the Command Palette and do "Remote-SSH: Kill VS Code Server on Host". Sometimes I need to do this multiple times for it to take effect. Then when I next log in there is a lengthy VS Code installation script that needs to run before I can start coding again.
Is there a way of setting up VS Code Remote SSH that avoids this issue? I have tried some of the suggestions on this page - https://code.visualstudio.com/docs/remote/troubleshooting. However I feel like I am completely in the dark regarding what the underlying issue is. I do not even know how I could go about generating informative diagnostics / a log.
Maybe the problem is that the remote machine has a limited number of proccess to run at same time. When a automatic disconnection of vscode happen, the that session is still running, but you cannot create a new one because you are over the limit in number of process.
In my case, asking to the remote machine to kill my process (manually done by the technician working in that machine in this case) works.
A better solution will be close the vscode sessions from your machine, to be able to start a new one again.
I can't figure this one out. I can't connect to a server using MySQL Workbench, I tried any kind of connection methods. The error message I get is
Failed to Connect to MySQL at AT 127.0.0.1:3306 with user root
Invalid for this platform protocol requested(MYSQL_PROTOCOL_SOCKET)
I ran into the same problem, in my case I originally created the connection with the "Local Socket/Pipe" option selected in the "Connection Method" drop down. Trying to switch back to "Standard (TCP/IP)" did not work and caused the error mentioned by OP. I had to delete the connection and start over by selection "Standard (TCP/IP)" from the start. The connection was successful after that.
To solve this problem you must check the "Others" field in Advanced tab
If you had the connection stored with a socket option you will find a "socket=." (or anything similar)
Delete it
e.g. http://prntscr.com/k63pua
This is a very unusal error message which I haven't seen before, especially on Windows. It has probably to do with how the server is installed. As a newbie it would definitely be the best choice to use the Windows Installer for all required parts. This will install the server properly too.
By using xampp you are on your own to check whether a server is installed and running as a service, as well as the proper configuration. For troubleshooting watch my video on Youtube where I tried to explain most common pitfalls for beginners.
Note: you can open the connection without actually being connected. In that case MySQL Workbench allows to do all those things that don't require a valid server connection, e.g. log file viewing, config file editing, service start/stop etc. Use this to check your server's configuration. Make sure it accepts TCP/IP connections (there's also a short section in the video about this).
Update:
Downvoter, please add a comment why you think my answer is bad.
Re-reading the error message I got another idea: could it be that you used local socket/named pipe for the connection? If so try with normal TCP/IP.
I have a large repository of C++ code on a remote cluster (linux OS). When I need to work on this code from my home computer (Ubuntu OS), I try to access these codes through emacs on X windows. However the X window connection is very slow making the editing a painful process. So I sometimes move files manually between my local drive and remote cluster to edit the files. My question is: is there a way to configure my local emacs, such that when I edit the file in my local space, it would automatically be backed up in the cluster where it can then be compiled?
UPDATE:1
I installed TRAMP and it works well for servers that can be connected directly. However I also have servers which can be connected only when I activate VPN. How to provide the VPN information to TRAMP to connect to this server?
The other question I had was how to stop the TRAMP when it waits for prompts from remote shell without having to kill the whole emacs buffer.
This is typically a use case where TRAMP would be useful.
Instead of connecting to the server using SSH and opening Emacs there with X forwarding, run Emacs on your box and open your files remotely using TRAMP. For example:
C-xC-f/ssh:user#host:/remote/path/to/the/fileRET
This way, your Emacs process runs locally, but all file operations (e.g. save, revert, ...) are forwarded to the server, and all shell commands issued from TRAMP buffers also run on the remote server (this includes M-x compile)
UPDATE:1
When TRAMP hangs waiting for a remote shell prompt (which tends to happen frequently for reasons which are still obscure to me), I usually kill the underlying ssh process (htop with tree-like view is a good tool to do this) . TRAMP notices this and automatically respawns the killed process to resume operations.
Wouldn't it be easier to run Emacs in a console on the remote server? All Emacs functions can be access via the keyboard and once you get used to the key combinations it usually works out faster.
That way you will be running faster than forwarding an X session - running in a console is what Emacs was designed for.
As an added bonus - if you get used to using Gnu screen - http://www.gnu.org/software/screen/ you can pick up your sessions exactly as they were if the connection drops. In fact with screen you can shutdown your laptop at the end of the day - login over SSH the next day and pick up all your 'screens' exactly as they were the day before. This will include any open editors, debug sessions etc.
Gnu screen is available as a package on Debian and probably most Linux distributions.
Lets say I have an Emacs-Server running on some remote server, with all the libraries and software necessary for running my application.
Then I want several clients to connect to that remote machine, using Emacs-client. Does each client need a full Emacs installation, or is there a minimal installation that is just enough to communicate with the remote server, where all the action is?
Could this (Emacs-)client installation be so minimal, that almost all software-updates can be done on the server, without affecting the Emacs-clients?
Is there a reason not to run the clients remotely as well, and simply use a local display? That way, pretty much all you need on the local machines is the ssh client and the X Window server.
ssh -X (user)#(server) "emacsclient -c"
Edits for the comments:
This command starts a new client to connect to an existing Emacs server (which it assumes is already running). You can use "emacsclient -a '' -c" to automatically start emacs --daemon if there is no existing server, but I don't know whether you want the connecting user to be starting the server.
In fact, I'm pretty unsure about the whole multi-user side of this to be honest, as I've never done that before. Authentication for the above is handled by ssh, but there may well be subsequent permission issues to deal with, or similar, when the server and the clients are started by different users.
This approach should be possible with Windows/Cygwin as client and/or server, as Cygwin provides Emacs, OpenSSH, and X.org packages. (I regularly use Windows/Cygwin as a local display for Emacs running on Linux.) It may be harder to set up, though, and any permissions issues are probably different when you're using Cygwin.
I'm less sure how this would work without Cygwin. NTEmacs certainly won't talk to X.org, so I imagine you'd be terminal based in that instance. (There are probably other options, but Cygwin sounds to me like the best-integrated approach to using all of Emacs, SSH, and X on Windows).
Lastly, I imagine you're probably getting your "Connection refused" error because localhost is not running a sshd daemon? I would say that configuration of ssh is outside the scope of this question, but there are lots of resources online for that.
Depending on what you're trying to achieve, you may be able to use a combination of Emacs and Screen. By starting up Emacs from Screen on the remote machine and detaching from it, you can subsequently re-attach from a different machine that doesn't have Emacs. Again, whether this will work for you or not depends on what you're trying to do; however, for many Emacs use-cases, this can be very effective. If you're not familiar with using Screen in this manner, here is some reading material:
screen - The Terminal Multiplexer
I am not sure that would be possible. emacsclient uses tramp to connect to a remote server, and just by looking at the number of requires in the tramp elisp files (41) it seems very unlikely. You can try it yourself with the following:
zgrep -oE "\(require '[a-z-]+\)" *el.gz | sed -e 's%[a-z0-9-]\+\.el\.gz:%%g' | sort | uniq -cu | wc -l
I'm not an expert in emacsclient, but I don't think is was designed to do what you're looking for. I think the general use case is that emacsclient allows you to redirect new requests to open a file with emacs to a persistent emacs process to avoid what may be a bit of an overhead in startup time. You seem to be looking for more of a true client/server relationship.
I think to meet the goal you're aiming at you'll probably need to look a little outside emacs, probably a project unto itself - 'emacsRemoteClient. It boils down to one or two models; the file you want to edit would need to have it's path sent over to the server machine so that emacs could do some sort of remote tramp access & then spawn the xwindow locally (using the local X env or requiring an x server on windows)... or two, transferring the file to some temp location on the server box and again spawning the remote x window locally (followed by syncing the changes between the tmp & local file).
Would be cool to have something like that... but suspecting it'll involve a bit of work. Maybe we just need a version of emacs written in javascript and it can live in the cloud or on your browser... oh to have emacs keybindings in the browser ;-)
-Steve
This page from the Emacs manual describes a function called make-frame-on-display that allows you to access a remote Emacs session. My interest in this function is to use it to share buffers for pair programming remotely with a colleague.
From the page:
It is even possible to use this feature to let two or more users type simultaneously on the two displays, within the same Emacs job. In practice, however, the different users can easily interfere with each others' edits if they are not careful.
How exactly do I set this up? What do I need? What does my partner need? The details are not stated, but I don't know enough about Emacs to know where to start.
Is there any other way to get a shared Emacs session? This page from the Emacs Wiki refers to something called multi-tty. The questions I asked above also apply to this.
Which is better: multi-tty or make-frame-on-display?
I haven't tried multi-tty, but make-frame-on-display is pretty simple. You type M-x make-frame-on-display, hit return, then type the display you want the frame to show up on. For example:
I have my local host (thor) running emacs and I want to make a frame pop up on a machine called zeus, on its only X display (0.0). So I would type M-x make-frame-on-display<ret>zeus:0.0<ret>
All set!
You may need to configure the remote machine's X server to accept incoming connections from your machine with "xhost +thor". You may also need to configure its firewall to allow incoming connections on the X11 port, which is 6000. Keep in mind that X forwarding is not encrypted, so if you aren't working with someone on your LAN you may want to go through a VPN in order to keep things private.
Edited to fix brackets.
You can also have the person at zeus type ssh -X thor emacsclient -c.
Did you ever consider using GNU screen on a shared account for pair programming? It's dead easy to get it to work and you get to pick any console based editor you and your partner like (emacs, vim, joe, nano, zile, ...). However, this does of course not work with editors that cannot run inside a terminal.
To set it up, create a shared account on a computer running ssh. Then both log in to that account. One of the partners starts screen with
screen
and the other connects to it with
screen -x
where -x means "attach to a not detached screen session". The users can detach from their sessions w/ "C-a d".
Old question, new solution for anyone landed on this page from year 2016.
I set this up in Ubuntu 14.04 and it works perfectly:
Suppose I want to co-edit or demo some cool stuffs on emacs with my colleague Joe on the other end of the world.
Make sure an ssh server with emacs installed at either end. That is, either MyPC or JoePC must be a SSH server and have Emacs installed. From now on, let's say I asked Joe to install SSH server and Emacs on his computer.
Make sure byobu is installed on JoePC. Byobu supports both tmux and screen as backends (I prefer tmux for a more mordern and feature-rich).
I connect to JoePC with ssh remoteuser#joepc. No need for X-forwarding.
Open emacs from byobu-ssh terminal: TERM=xterm-256color && emacsclient --alternate-editor="" -t. One can make an alias for this command. I recommend this long command because it enables both better color support in the terminal and running Emacs in daemon mode. The daemon mode make it fast to close and reopen frames.
Now the magic unfold: Ask Joe to login with the same remoteuser I am loggin in; open the terminal and start byobu if it hasn't for him.
Start hacking or fumbling :-)
Comment:
Because the way byobu work. This approach works for any other program inside the byobu terminal.
This setup performs much better than Teamviewer or any other GUI remote desktop solutions.
Because the connection is through ssh to the remote server directly, it is as secure as the ssh conenction can offer.