Cloud Station fehlerhafte conf/client.conf Datei auf Windows Client

[swiffer]

Hey nach einem Update und Neuverbindung der CloudStation kam es bei meinen beiden Windows Clients zu fehlerhaften Einträgen in der client.conf (hier wurde eine feste IP eingetragen, die am nächsten Morgen nach Router Reconnect nicht mehr funktionierte, hat das Problem sonst noch einer gehabt ?

ConnectionMode="DirectConnect"
port="6690"
server="88.78.XXX.XX"
serverID=""
serverName="88.78.XXX.XX"

bei serverName habe ich nun aber die Adresse eingetragen (XXX.dscloud.me) und es funktioniert wieder ohne Probleme...

 

[hagge]

jap, habe genau dasselbe Problem.
Nach starten des Clients dauert es eine Weile, bis dieser "reconnecting" meldet. Danach ist der DDNS Eintrag in der client.conf gegen eine statische IP ersetzt :-/

 

[Trolli]

Könnt ihr mal bitte versuchen statt der DynDNS die ezCloud-ID einzugeben?

 

[hagge]

habe ich gerade versucht.
Der Client meldet erst (vermutlich fehlerhafter Weise), dass alles in Ordnung und synchron sei (gruener Haken). Nach etwa einer Minute meldet er dann "reconnecting" ...
Das tut er nun seit 5 Minuten

...Ich sollte allerdings dazu sagen, dass mein Arbeitgeber fast saemtliche ausgehende Ports blockiert. Habe daher den Port des Clients auf 995 (Pop3s) gestellt und einen entsprechenden "virtuellen Server" im Router eingerichtet. Im Assistenten beim ersten Start des Clients habe ich den Port dann in der Server-Adresse angegeben:
blabla.mydyndns.org:995
was auch vorbildlich in der client.conf unter "port" eingeordnet wird und alles funktioniert zunaechst einwandfrei (ohne ezCloud-ID)

Nach Neustart des Clients tritt der oben genannte Effekt auf...

Ach und noch etwas anderes (ich weiss nicht, ob das an dieser Stelle angemessen ist, aber):
Ich habe gestern bereits versucht, dasselbe Problem im englischen Forum unter:
http://forum.synology.com/enu/viewforum.php?f=197
zu melden. Irgendwie wurde mein Beitrag aber offenbar nicht "akzeptiert" (?)
Habe einen Link zu dem Beitrag im "Privaten Bereich", der dann meldet "Das von dir ausgewählte Thema existiert nicht."

 

[goetz]

Hallo,

Irgendwie wurde mein Beitrag aber offenbar nicht "akzeptiert" (?)

wenn Du dort noch nicht aktiv warst muß/müssen der/die erste/ersten Beitrag/Beiträge von einem Moderator freigeschaltet werden, Spamschutz. Weiß jetzt nicht mehr ob es nur der erste war.

Gruß Götz

 

[hagge]

@goetz:
ah, ok, ja, war der erste. Dann wurde der wohl entweder noch nicht gelesen oder als Spam gewertet :-O
Aber dann ist der Punkt wohl schon mal geklaert.

 

[Puzzelkoenig]

Moin...

Ich habe mit der Clientsoftware auch das Problem, das es am nächsten Morgen immer die IP und nicht den Dyndns-Namen drinnen hat.
Erst versucht er sich zu verbinden u. das klappt dann natürlich nicht. Erst wenn ich die Verbindung trenne u. dann den Namen wieder eintrage, funktioniert es wieder. Ist die EZ-Cloud-ID eindeutig oder ist die Variante über die Conf.Datei die Lösung.
Habe natürlich keine Lust, jeden Tag die Daten neu einzutragen...
Gruß

 

[hagge]

...
also bei mir hat auch die ezId nichts gebracht.
Man kann die client.conf schreibschuetzen :-O ... dann meldet der Client aber alle 2 Minuten "reconnecting". Irgendwie will der offenbar also schon sehr gerne ne "richtige IP" in seiner Konfiguration haben.
Man kann ansonsten die client.conf vor jedem Client start mit einer vorgefertigten "richigen" Datei ueberschreiben... Allerdings sind mir auch noch weitere Probleme aufgefallen. So scheint mein Client gelegentlich beim Synchronisieren einzelner Dateien "festzuklemmen". Man entdeckt im Task-Manager einen "client-win" Prozzess mit 50% dauerhafter CPU Last (auf nem dual core... also vielleicht sinds 100% auf nem single...).
In meinem Fall passiert das, wenn ich ein Latex-Dokument im CloudStation Ordner Kompiliere... Vielleicht entsteht das Problem durch gleichzeitigen Zugriff verschiedener Prozesse auf dieselbe Datei (?)

Ausserdem zeigt der Client teilweise "gruene Haken" an Dateien, die tatsaechlich noch nicht wieder "in sync" sind... Das ist mir fuer meine Zwecke grad' zu riskant.

Ich hab den Client nun erst mal (schweren Herzens) wieder deaktiviert und warte auf das Ende der BETA Phase

 

[Puzzelkoenig]

Kleines Update:
Ich habe mich mal an den Syno-Support gewendet u. auch eine Antwort bekommen. In den Cloudeinstellungen soll ich eine eigene ezID erstellen u. die dann auf den jeweiligen Clients eingeben.
Gesagt u. getan u. prompt läuft alles seit 3 Tagen ohne Fehler durch. Warum das Clienttool alle andere Daten immer abgeändert hat, aber dann nicht die selbsterstellt ezID, keine Ahnung.
Wie gesagt, einfach mal eigenen ID erstellen u. testen..
Gruß

 

[hagge]

...hmm, habe auf Puzzelkoenigs Kommentar hin noch einmal dasselbe versucht.
Kurz: bei mir funktioniert das leider immer noch nicht.
Liegt aber vielleicht wirklich an meiner veraenderten Port-einstellung...

Da ich den Client zuvor bereits deinstalliert hatte, hab ich den soeben "frisch" neu installiert und die Adresse ueber den "Assistenten" einzugeben versucht.
Hier faellt auf, dass ich der ezId schon mal keinen Port zuordnen kann. Also die Eingabe
XXXXXXXXX:995
fuert sofort zur Fehlermeldung "invalid ID"
selbiges passiert, wenn ich statt ez Nummer den entsprechenden Alias plus Portangabe verwende.
Trage ich nur die ezId (ohne Port) ein, meldet er 'nen "Verbindungsproblem" (vermutlich wegen der hiesigen ausgehenden Port-Sperre)

Trage ich fuer die Erstverbindung den dyndns namen + Port ein, funktionierts zunaechst (wie bereits erwaehnt).
Habe nun noch mal versucht, in der client.conf nachtraeglich alle 3 Felder:
server="XXXXXXXXX"
serverID="XXXXXXXXX"
serverName="XXXXXXXXX"
auf meine ez ID nummer zu setzen...
Es folgt oben beschriebener Effekt:
Erst gruener Haken, dann "reconnect" und ne kleine graue Wolke mit nem 'x' in der Taskleiste :-(

 

[Puzzelkoenig]

Hallo Hagge,

einfach nur bei der Syno in den Cloudeinstellungen eine eigene ID erstellen. Hatte zu Anfang auch meine Probleme, weil er die Zahlenkombination angemeckert hat. Habe dann an den Anfang einfach zwei Buchstaben gesetzt + die entsprechende Anzahl an Zahlen. Auf jeden Fall habe ich in der ID keine Portfreigabe drinnen, das erledigt mein Router.
Im Client selber habe ich dann die von mir generierte ID eingetragen u. bis jetzt läuft es ohne Fehler.
Die Conf-Datei habe ich nicht angefasst. Testweise habe ich noch einen Freund reingehängt u. da läuft es auch ohne Fehler.

 

[hagge]

@Puzzelkoenig: ich vermute, du hast einfach NICHT das Problem, dass auf deinem "Arbeitsrechner" ausgehende Ports gesperrt werden...
Also du meinst mit ID doch das, was unter DSM -> Systemsteuerung -> ezCloud -> QuickConnect als
"ezCloud-ID benutzerdefinieren" steht, oder?

Also ich habe da einmal die "ezCloud-ID", die eine 9-stellige Nummer darstellt und dann eben dieses "ezCloud-ID benutzerdefinieren" (soll vermutlich eigentlich "benutzerdefinierte ezCloud-ID" heissen), die bei mir nun eine freundliche Buchstabenfolge ist.
Egal, welche der beiden IDs ich im Assistenten angebe, die Verbindung schlaegt fehl mit der genauen Meldung:
"Connection failed. Please check your network settings and try again"
Also ich brauche halt den "Umweg" ueber einen anderen Port...

 

[wolfda]

So, ich hab das gleiche Problem.
Der Support ist etwas sinnfrei bei Synology. Was ist mit den Leuten die keine ezCloud ID nutzen möchten?
Bei mir wird "cloud.meinedomain.de" auch ständig überschrieben. Und es nervt - die werden wohl mal in der Lage sein
die .conf so anzupassen das sie die Domain nicht jedes mal durch eine IP ersetzt. Sind wir in der Steinzeit oder was?

 

[wolfda]

Die beste Lösung ist wirklich Dateischreibschutz aktivieren und unter Windows "Symbol und Benachrichtigungen ausblenden" (Rechtsklick auf Taskleiste > Eigenschaften > Infobereich)

 

[hagge]

Rechtsklick auf Taskleiste > Eigenschaften > Infobereich

möglicherweise coole Idee, klappt aber leider nicht unter XP :-/

Sind wir in der Steinzeit oder was?

...hmnajaaa... ist halt noch 'ne BETA. Das wird schon noch.

 

[wolfda]

Halt Kommando zurück, die Cloudstation synchronisiert die Dateien nicht mehr wenn auf der client.conf ein Schreibschutz liegt.
Ich hab das jetzt anders gelöst. Von der client.conf hab ich mir eine Kopie erstellt mit dem gewünschtem Inhalt.
Im gleichen Verzeichnis hab ich eine Batch-Datei mit folgendem Inhalt angelegt:

copy client_backup.conf client.conf
cd..
start cloud.exe

Noch eine Verknüpfung zur Batch-Datei in den Autostart und fertig.

@hagge
... im XP kannst du die Symbole auch ausblenden. (Rechtsklick auf Taskleiste > Eigenschaften > Inaktive Symbole ausblenden > Verhalten > Immer ausblenden)