Connection with server lost when using Unison over SSH
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
I have a file server running Raspbian and a workstation running Ubuntu MATE 16.04. I use Unison to keep my home directory in sync. I’ve set it up to use a SSH connection.
The workstation runs Unison 2.48; the server has multiple versions (including 2.48). I’ve successfully propagated a couple of changes from the workstation to the server that way.
Now I’ve changed a file on the server. Unison looks for changes and correctly suggests updating the local copy with the file from the server.
However, when I click Go, I get the following error:
Fatal error
Lost connection with the server.
Unison settings are as follows:
# Unison preferences
label = Home dir
root = /home/me
root = ssh://me@fileserver//srv/file/me
sshargs = -C
addversionno = true
dontchmod = true
perms = 0
path = Documents
path = Pictures
General configuration problems (missing Unison version on server, wrong path etc.) are unlikely as changes are being detected and I have synchronized data various times (always workstation to server). It’s just the server-to-workstation scenario that fails.
I decided to “sacrifice” my edits to the new file and chose to replace the server version with the outdated local one. Surprisingly, that sync run completed successfully—everything works unless there are changes on the server side.
What’s happening here?
ssh unison
asked Jan 15 '17 at 16:40
user149408
210210
add a comment |
up vote
1
down vote
favorite
I have a file server running Raspbian and a workstation running Ubuntu MATE 16.04. I use Unison to keep my home directory in sync. I’ve set it up to use a SSH connection.
The workstation runs Unison 2.48; the server has multiple versions (including 2.48). I’ve successfully propagated a couple of changes from the workstation to the server that way.
Now I’ve changed a file on the server. Unison looks for changes and correctly suggests updating the local copy with the file from the server.
However, when I click Go, I get the following error:
Fatal error
Lost connection with the server.
Unison settings are as follows:
# Unison preferences
label = Home dir
root = /home/me
root = ssh://me@fileserver//srv/file/me
sshargs = -C
addversionno = true
dontchmod = true
perms = 0
path = Documents
path = Pictures
General configuration problems (missing Unison version on server, wrong path etc.) are unlikely as changes are being detected and I have synchronized data various times (always workstation to server). It’s just the server-to-workstation scenario that fails.
I decided to “sacrifice” my edits to the new file and chose to replace the server version with the outdated local one. Surprisingly, that sync run completed successfully—everything works unless there are changes on the server side.
What’s happening here?
ssh unison
asked Jan 15 '17 at 16:40
user149408
210210
1
I wonder if the problem could be with the underlying SSH connection. What do the following commands do?ssh me@fileserver head -c 100k /dev/urandom | wc -candhead -c 100k /dev/urandom | ssh me@fileserver wc -c
– Gilles
Jan 15 '17 at 22:14
Both show102400. That looks to me like the SSH connection isn’t the problem.
– user149408
Jan 19 '17 at 23:47
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I have a file server running Raspbian and a workstation running Ubuntu MATE 16.04. I use Unison to keep my home directory in sync. I’ve set it up to use a SSH connection.
The workstation runs Unison 2.48; the server has multiple versions (including 2.48). I’ve successfully propagated a couple of changes from the workstation to the server that way.
Now I’ve changed a file on the server. Unison looks for changes and correctly suggests updating the local copy with the file from the server.
However, when I click Go, I get the following error:
Fatal error
Lost connection with the server.
Unison settings are as follows:
# Unison preferences
label = Home dir
root = /home/me
root = ssh://me@fileserver//srv/file/me
sshargs = -C
addversionno = true
dontchmod = true
perms = 0
path = Documents
path = Pictures
General configuration problems (missing Unison version on server, wrong path etc.) are unlikely as changes are being detected and I have synchronized data various times (always workstation to server). It’s just the server-to-workstation scenario that fails.
I decided to “sacrifice” my edits to the new file and chose to replace the server version with the outdated local one. Surprisingly, that sync run completed successfully—everything works unless there are changes on the server side.
What’s happening here?
ssh unison
asked Jan 15 '17 at 16:40
user149408
210210
I have a file server running Raspbian and a workstation running Ubuntu MATE 16.04. I use Unison to keep my home directory in sync. I’ve set it up to use a SSH connection.
The workstation runs Unison 2.48; the server has multiple versions (including 2.48). I’ve successfully propagated a couple of changes from the workstation to the server that way.
Now I’ve changed a file on the server. Unison looks for changes and correctly suggests updating the local copy with the file from the server.
However, when I click Go, I get the following error:
Fatal error
Lost connection with the server.
Unison settings are as follows:
# Unison preferences
label = Home dir
root = /home/me
root = ssh://me@fileserver//srv/file/me
sshargs = -C
addversionno = true
dontchmod = true
perms = 0
path = Documents
path = Pictures
General configuration problems (missing Unison version on server, wrong path etc.) are unlikely as changes are being detected and I have synchronized data various times (always workstation to server). It’s just the server-to-workstation scenario that fails.
I decided to “sacrifice” my edits to the new file and chose to replace the server version with the outdated local one. Surprisingly, that sync run completed successfully—everything works unless there are changes on the server side.
What’s happening here?
ssh unison
ssh unison
asked Jan 15 '17 at 16:40
user149408
210210
asked Jan 15 '17 at 16:40
user149408
210210
edited Jan 15 '17 at 17:19
asked Jan 15 '17 at 16:40
user149408
210210
asked Jan 15 '17 at 16:40
user149408
210210
asked Jan 15 '17 at 16:40
user149408
210210
210210
1
I wonder if the problem could be with the underlying SSH connection. What do the following commands do?ssh me@fileserver head -c 100k /dev/urandom | wc -candhead -c 100k /dev/urandom | ssh me@fileserver wc -c
– Gilles
Jan 15 '17 at 22:14
Both show102400. That looks to me like the SSH connection isn’t the problem.
– user149408
Jan 19 '17 at 23:47
add a comment |
1
I wonder if the problem could be with the underlying SSH connection. What do the following commands do?ssh me@fileserver head -c 100k /dev/urandom | wc -candhead -c 100k /dev/urandom | ssh me@fileserver wc -c
– Gilles
Jan 15 '17 at 22:14
Both show102400. That looks to me like the SSH connection isn’t the problem.
– user149408
Jan 19 '17 at 23:47
1
1
I wonder if the problem could be with the underlying SSH connection. What do the following commands do?
ssh me@fileserver head -c 100k /dev/urandom | wc -c and head -c 100k /dev/urandom | ssh me@fileserver wc -c– Gilles
Jan 15 '17 at 22:14
I wonder if the problem could be with the underlying SSH connection. What do the following commands do?
ssh me@fileserver head -c 100k /dev/urandom | wc -c and head -c 100k /dev/urandom | ssh me@fileserver wc -c– Gilles
Jan 15 '17 at 22:14
Both show
102400. That looks to me like the SSH connection isn’t the problem.– user149408
Jan 19 '17 at 23:47
Both show
102400. That looks to me like the SSH connection isn’t the problem.– user149408
Jan 19 '17 at 23:47
add a comment |
2 Answers
2
active
oldest
votes
up vote
0
down vote
I think here is a solution:
NB- this is usually because the option PermitUserEnvironment in /etc/sshd_config is set to 'no' (for example, MacOSX ships with this set to NO). You should be able to set it to 'yes' and things will be golden.
https://alliance.seas.upenn.edu/~bcpierce/wiki/?n=Main.UnisonFAQTroubleshooting
But only on my machine sshd_config is placed under /etc/ssh
answered Feb 20 '17 at 10:10
theotheo
1011
The FAQ gives this as the reason for the connection failing completely. However, in my case the initial connection is successful—I can list changes, and even upload local changes—it is just pulling remote changes which fails. I’ll give it a try and report back.
– user149408
Feb 20 '17 at 15:21
add a comment |
up vote
0
down vote
I had the exact same problem (with Mint 18.2 KDE Edition).
I appears that the version of Unison compiled for this version of Linux Mint is the problem. Using the Unison from Debian repository solved the problem.
I downloaded the package "unison-gtk_2.48.3-1_amd64.deb" from Debian packages repository, and install the new binary by hand (extracting the files at the correct places) and using Debian alternative to let the Mint Unison and the Debian Unison co-exist. There may be a smarter way to install a Debian package on Mint, but this was a fast proof-of-concept.
answered Feb 4 at 17:26
Skiron
11
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
I think here is a solution:
NB- this is usually because the option PermitUserEnvironment in /etc/sshd_config is set to 'no' (for example, MacOSX ships with this set to NO). You should be able to set it to 'yes' and things will be golden.
https://alliance.seas.upenn.edu/~bcpierce/wiki/?n=Main.UnisonFAQTroubleshooting
But only on my machine sshd_config is placed under /etc/ssh
answered Feb 20 '17 at 10:10
theotheo
1011
The FAQ gives this as the reason for the connection failing completely. However, in my case the initial connection is successful—I can list changes, and even upload local changes—it is just pulling remote changes which fails. I’ll give it a try and report back.
– user149408
Feb 20 '17 at 15:21
add a comment |
up vote
0
down vote
I think here is a solution:
NB- this is usually because the option PermitUserEnvironment in /etc/sshd_config is set to 'no' (for example, MacOSX ships with this set to NO). You should be able to set it to 'yes' and things will be golden.
https://alliance.seas.upenn.edu/~bcpierce/wiki/?n=Main.UnisonFAQTroubleshooting
But only on my machine sshd_config is placed under /etc/ssh
answered Feb 20 '17 at 10:10
theotheo
1011
The FAQ gives this as the reason for the connection failing completely. However, in my case the initial connection is successful—I can list changes, and even upload local changes—it is just pulling remote changes which fails. I’ll give it a try and report back.
– user149408
Feb 20 '17 at 15:21
add a comment |
up vote
0
down vote
up vote
0
down vote
I think here is a solution:
NB- this is usually because the option PermitUserEnvironment in /etc/sshd_config is set to 'no' (for example, MacOSX ships with this set to NO). You should be able to set it to 'yes' and things will be golden.
https://alliance.seas.upenn.edu/~bcpierce/wiki/?n=Main.UnisonFAQTroubleshooting
But only on my machine sshd_config is placed under /etc/ssh
answered Feb 20 '17 at 10:10
theotheo
1011
I think here is a solution:
NB- this is usually because the option PermitUserEnvironment in /etc/sshd_config is set to 'no' (for example, MacOSX ships with this set to NO). You should be able to set it to 'yes' and things will be golden.
https://alliance.seas.upenn.edu/~bcpierce/wiki/?n=Main.UnisonFAQTroubleshooting
But only on my machine sshd_config is placed under /etc/ssh
answered Feb 20 '17 at 10:10
theotheo
1011
answered Feb 20 '17 at 10:10
theotheo
1011
answered Feb 20 '17 at 10:10
theotheo
1011
answered Feb 20 '17 at 10:10
theotheo
1011
1011
The FAQ gives this as the reason for the connection failing completely. However, in my case the initial connection is successful—I can list changes, and even upload local changes—it is just pulling remote changes which fails. I’ll give it a try and report back.
– user149408
Feb 20 '17 at 15:21
add a comment |
The FAQ gives this as the reason for the connection failing completely. However, in my case the initial connection is successful—I can list changes, and even upload local changes—it is just pulling remote changes which fails. I’ll give it a try and report back.
– user149408
Feb 20 '17 at 15:21
The FAQ gives this as the reason for the connection failing completely. However, in my case the initial connection is successful—I can list changes, and even upload local changes—it is just pulling remote changes which fails. I’ll give it a try and report back.
– user149408
Feb 20 '17 at 15:21
The FAQ gives this as the reason for the connection failing completely. However, in my case the initial connection is successful—I can list changes, and even upload local changes—it is just pulling remote changes which fails. I’ll give it a try and report back.
– user149408
Feb 20 '17 at 15:21
add a comment |
up vote
0
down vote
I had the exact same problem (with Mint 18.2 KDE Edition).
I appears that the version of Unison compiled for this version of Linux Mint is the problem. Using the Unison from Debian repository solved the problem.
I downloaded the package "unison-gtk_2.48.3-1_amd64.deb" from Debian packages repository, and install the new binary by hand (extracting the files at the correct places) and using Debian alternative to let the Mint Unison and the Debian Unison co-exist. There may be a smarter way to install a Debian package on Mint, but this was a fast proof-of-concept.
answered Feb 4 at 17:26
Skiron
11
add a comment |
up vote
0
down vote
I had the exact same problem (with Mint 18.2 KDE Edition).
I appears that the version of Unison compiled for this version of Linux Mint is the problem. Using the Unison from Debian repository solved the problem.
I downloaded the package "unison-gtk_2.48.3-1_amd64.deb" from Debian packages repository, and install the new binary by hand (extracting the files at the correct places) and using Debian alternative to let the Mint Unison and the Debian Unison co-exist. There may be a smarter way to install a Debian package on Mint, but this was a fast proof-of-concept.
answered Feb 4 at 17:26
Skiron
11
add a comment |
up vote
0
down vote
up vote
0
down vote
I had the exact same problem (with Mint 18.2 KDE Edition).
I appears that the version of Unison compiled for this version of Linux Mint is the problem. Using the Unison from Debian repository solved the problem.
I downloaded the package "unison-gtk_2.48.3-1_amd64.deb" from Debian packages repository, and install the new binary by hand (extracting the files at the correct places) and using Debian alternative to let the Mint Unison and the Debian Unison co-exist. There may be a smarter way to install a Debian package on Mint, but this was a fast proof-of-concept.
answered Feb 4 at 17:26
Skiron
11
I had the exact same problem (with Mint 18.2 KDE Edition).
I appears that the version of Unison compiled for this version of Linux Mint is the problem. Using the Unison from Debian repository solved the problem.
I downloaded the package "unison-gtk_2.48.3-1_amd64.deb" from Debian packages repository, and install the new binary by hand (extracting the files at the correct places) and using Debian alternative to let the Mint Unison and the Debian Unison co-exist. There may be a smarter way to install a Debian package on Mint, but this was a fast proof-of-concept.
answered Feb 4 at 17:26
Skiron
11
answered Feb 4 at 17:26
Skiron
11
answered Feb 4 at 17:26
Skiron
11
answered Feb 4 at 17:26
Skiron
11
11
add a comment |
add a comment |
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f337590%2fconnection-with-server-lost-when-using-unison-over-ssh%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
I wonder if the problem could be with the underlying SSH connection. What do the following commands do?
ssh me@fileserver head -c 100k /dev/urandom | wc -candhead -c 100k /dev/urandom | ssh me@fileserver wc -c– Gilles
Jan 15 '17 at 22:14
Both show
102400. That looks to me like the SSH connection isn’t the problem.– user149408
Jan 19 '17 at 23:47