By default, VSCode Remote SSH "mounts" itself at ~/.vscode-remote. I have two different servers that share the same home directory that's network shared, so I can't connect to both instances at once without some weird things happening (e.g. if I edit a file in one instance, the other instance disconnects - I imagine they're overwriting each other and clashing somehow).
It would be great if it was possible to specify in some config file where we want VSCode to install itself on the remote machine.
Version of VSCode: 1.35.0
Remote connection type: SSH
OS: Win10
Remote OS: Ubuntu 14.04 on both servers
Extensions: just the Python one, but I imagine this is irrelevant
Reproducible steps:
1) get two different servers that share the same home directory
2) try to connect to both at the same time
3) do various things (R/W operations) on one machine and the other machine's connection will be interrupted/closed
Expectation: be able to work on two machines at once that share the same home directory by being able to change where VSCode Remote installs
Thanks!
i'm also with a shared home directory and it has a very limited quota. i'd rather not keep binaries on it. i need to have per-host configuration of where .vscode-remote is placed, or even better if the location is controlled by some environment variable from the remote system.
I am running into exactly the same problem. I connect to a bunch of remote servers that share the same home directory (nfs). The problem is not just that the sessions can't exist simultaneously, it's worse- only the session from the last connected server will work. Trying to connect to a server/session that was used earlier fails. Only solution at that point is to delete the .code-server directory.
Same issue here when running on a managed VPS from someone like cloud ways - You can't create new folders in the home directory.
Seems logical that you should be able to specify a different location for the folder to live.
I also have the same problem... Is there any solution for that?
I guess no solutions yet? I was trying to find the source code of the extension itself. Is it publicly available? I mean, this sounds like a pretty easy thing to customize the server directory for different hosts.
I'd need this too. Remote server does not grant wrtite permissions to home directory itself, only subdirectories :(
Another use case - many ec2 instances where the only configured user is ec2-user.
One possible solution here is to look at the SSH_CLIENT env variable:
SSH_CLIENT=10.1.17.246 34712 22
This is unique for each login source, so everyone that may be using one of these systems uses a unique and consistent SSH_CLIENT variable.
If one could specify a script to run on the target to generate the .vscode-server dir name to use.
eg:
$> ~/bin/gen-vscode-server-dir.sh
~/ec2-user/.10.1.17.246.vscode-server <- returns dir name to use
This should work for all of the above use cases.
Perhaps another option is to have a fallback/flexibility is for a local script to run first with the hostname as a parameter. This way, if the remote script doesn't, the local script could upload it, then retry the process.
eg: run locally:
~/bin/upload-gen-vscode-server-dir.sh <- uploads gen-vscode-server-dir.sh to ~/bin
run remote:
$> ~/bin/gen-vscode-server-dir.sh
~/ec2-user/.10.1.17.246.vscode-server <- returns dir name to use
I managed to workaround this issue for the scenario with several machine with the same network home by creating symlink to the local dir:
cd /users/my_user
mkdir .vscode-server
ln -s /users/my_user/.vscode-server ~/.vscode-server
You need to create /users/my_user/.vscode-server on every machine that you are going to use, of course.
not completely on-topic, but i noticed that the cpptools extension also stores a lot of data in home, under ~/.cache/vscode-cpptools .
not completely on-topic, but i noticed that the cpptools extension also stores a lot of data in home, under ~/.cache/vscode-cpptools .
There is a settings options for that called C_Cpp.intelliSenseCachePath which lets you choose a custom path for the precompiled headers that it is storing in the .cache folder
I am noticing that this issue seems to have stalled as it has been open for nearly a year. Is it still being considered for development? Setting an initial directory upon connect is usually a simple process. Since this is SO important for the vast majority of us, I am concerned it is not being triaged properly.
We have an additional rub from this issue in that we have home directories mapped to multiple systems with different architectures (x86, arm, and powerpc). Unfortunately, you can't have multiple installs of the server, and so when connecting to the ARM after installing on x86, you get an error due to the invalid binary format.
@dbabokin I was just wondering if symlink is the right solution for this. My home directory is on NFS and quite slow, really. Will there be noticeable speed differences if I move my ~/.vscode-server directory to an SSD and symlink it?
@dufferzafar First use of the machine and installing new extensions is slow, but other than that it works pretty well for me. But it's just a workaround for the problem.
@dbabokin Why is first use and extension install slow? That seems counter intuitive. If we're moving things off NFS and onto SSD then shouldn't it be faster?
But I do agree that this is just a workaround. It'd be great to have this supported by the extension itself.
@dufferzafar good point, I haven't compared it with NFS location, just noticed that it's slow. Probably it's just due to download speed. Hosting the folder on NFS location is not an options for me at all - due to size limits for the home folder.
My HACK:
First I need the server know the SSH session is from VSCode, I don't have a "good" way.
{ "remote.SSH.configFile": "C:/Users/GongT/.ssh/config-vscode" }
SendEnv USERNAME
Include ~/.ssh/config
AcceptEnv USERNAME
Then I need a monkey patch.
Place this file at /dev/profile.d/vscode.sh
case "$0" in
*bash*)
;;
*)
return # not BASH
esac
case "$-" in
*i*)
return # is interactive
esac
if [[ "$USERNAME" ]]; then
echo "Detected VSCode session; USERNAME=$USERNAME; SSH process PID is $$" >&2
unset USERNAME
if [[ "$PROXY" ]]; then
export http_proxy="$PROXY" https_proxy="$PROXY"
echo "Using proxy for download VSCode server: $PROXY" >&2
fi
declare -xr VSCODE_SERVER_HACK_ROOT=/data/AppData/VSCodeRemote
function ns_exec() {
set -x
unshare --pid --fork --kill-child --mount-proc --propagation=unchanged "$@"
}
function bash() {
sed "s|export VSCODE_AGENT_FOLDER=|export VSCODE_AGENT_FOLDER=$VSCODE_SERVER_HACK_ROOT # |g" \
| ns_exec /usr/bin/bash "$@"
}
fi
馃挦馃挦馃挦
.vscode-server(-insiders) awayIs this request being worked on?
I too would like to see this feature in VS code. Is there any update?
When will this be completed? Our home directories are stored remotely and as such this is adding latency. Do I need to symlink them?
I also need this. I having the same issue since VSCode Remote was released. Multiple servers with a shared home. I had to create multiple local users like: username-vscode, but it is by far not the best solution.
Another vote for this -- ideally it could read an environment variable upon installation and install it wherever it is pointed.
+1 for this feature request.
I would like to point out that in some environments you have no say in how the remote system is setup. You don't get a personal user account on the remote host but are forced to share a "group account" with multiple people. Being able to specify the directory on the remote would allow using the extension without messing up other peoples environment.
+1 for my managed where i have no permissions on the root
+1. No permission on root and this extension is not usable.
This is a really helpful feature. In my case, I need to share home dir but I don't want others to share my extensions.
+1 for the feature is needed. Limited quota on disk and the storage is shared across the cluster. Currently doing the hack of symlinks on every machine (+50). Would be much better if the location of vscode-server is configurable.
+1 for this feature request. Would be much better if the location of vscode-server is configurable.
Unusable on cloudways for this reason.
+1 for this feature request. All my remote machines shares the same shared home directory and sometime it fails connecting to one of the remote server
+1 for this feature request.
Most helpful comment
Is this request being worked on?