Bereiche
News
Rewind
Tipps & Berichte
Forum
Galerie
Journals
Events
Umfragen
Themenwoche
Kleinanzeigen
Interaktiv
Anmelden
Registrierung
Zu allen empfangenen Nachrichten
Suche...
Zur erweiterten Suche
Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?
Forum
>
Netzwerke
>
Synology: Extern Zugriff via DDNS für HyperBack klappt nicht
Synology: Extern Zugriff via DDNS für HyperBack klappt nicht
Cornelius Fischer
26.08.24
17:15
Hoi zusammen, ich versuche gerade ein 2. NAS zuhause einzurichten, so dass es als Backup Target für einen Kollegen funktioniert. Leider bekommen wir keine Verbindung von Aussen auf das Backup-NAS hin. HyperBack meldet immer der Hostname sei falsch oder das Sicherungsziel befindet sich hinter NAT und die Portweiterleitungn sei nicht korrekt.
Folgendes zum Setup (bei mir zuhause):
Modem im Bridge Modus (heute nochmals vom ISP bestätigt)
Router RT2600ac
Portweiterleitung und Firewall auf RT2600ac sind korrekt eingetragen
DDNS Verbindung vom 2. NAS sind grün (verbunden)
Wenn ich auf den 2. NAS (bei mir) versuche die Routerkonfiguration laufen zu lassen, meldet der Assistent immer, es gäbe mehr als einen Router.
Ich hab ein Site-to-Site VPN zwischen meinem Büro (da steht ein RT6600ax) und meinem Zuhause mit dem RT2600ac. Kann diese VPN-Verbindung den externen Zugriff am Zuhause Standort stören? 🤔
Und was mir auf aufgefallen ist und sehr komisch ist, nehme ich die DDNS vom 2. NAS (bei mir zuhause) und geb die im Browser ein, lande ich beim SRM Login vom RT2600ac (bei mir zuhause), obwohl der extern Zugriff auf SRM blockiert ist in den Router Einstellungen.
Hilfreich?
0
Kommentare
TomDsh
26.08.24
17:31
Könntest Du bitte das ganze mal aufzeichnen? Handschriftlich und Foto hier einstellen würde reichen. Aus den Schilderungen ist für mich nicht klar verständlich, wieviele Geräte beteiligt sind und wer jetzt welchen Netzwerk-Dienst bereitstellt.
Hilfreich?
-1
MikeMuc
26.08.24
17:59
Portfreigaben für sowas sind „doof“ ( eigentlich sind die fast immer unangebracht). Mach es über ein VPN. Und dann nicht mit Hostnamen weil die immer nur lokal gelten sondern mit festen IP Adressen. Das macht vieles einfacher
Hilfreich?
0
Cornelius Fischer
26.08.24
18:22
VPN Verbindung vom Quell-NAS zum Ziel hab ich mittlerweile einrichten können. Das Quell-NAS verbindet nun per VPN Plus Server auf dem Router (RT2600ac) mit dem lokalen LAN. Wenn ich nun beim Quell-NAS die Verbindung per IP Adresse in HyperBackup aufbauen möchte, kommt weiterhin folgende Fehlermeldung (siehe Bild)
Mir ist es ein Rätsel…
- IP der Ziel ist korrekt, Verbindung per VPN ist aktiv (keine Fehler in den Protokollen)
- Sicherungsdienst auf dem Ziel (HyperBackup Vault) ist installiert und läuft
- Ziel-NAS hat einwandfreie Netzwerkverbindung (greife selber gerade per VPN von extern auf das Ziel zu)
- Sicherungsziel ist nun nicht mehr hinter NAT (weil ja VPN), Portweiterleitung sollte ja nun irrelevant sein)
- Firewall auf Ziel-NAS ist deaktiviert. Am Router sollte es ja keine speziellen Firewall Settings benötigen, weil Verbindung per VPN kommt.
Any ideas?
MikeMuc
Portfreigaben für sowas sind „doof“ ( eigentlich sind die fast immer unangebracht). Mach es über ein VPN. Und dann nicht mit Hostnamen weil die immer nur lokal gelten sondern mit festen IP Adressen. Das macht vieles einfacher
Hilfreich?
0
sudoRinger
26.08.24
19:10
Ich habe den gleichen Synology-Router und zwei Synology-NAS.
Bei zwei DDNS im gleichen Netz funktioniert das Port Forwarding nicht und Du müsstest noch Port Triggering einsetzen.
Einfacher ist es, Du nutzt die DDNS vom ersten NAS auch für NAS2. Das kannst Du mit einem Reverse Proxy erreichen, welches in DSM/Anmeldeportal/Erweitert eingerichtet wird.
Es empfiehlt sich für das NAS1 ein Wildcard-Zertifikat für eine Synology-Domain einzurichten. Dann kannst Du mit nas1.cf.synology.me das NAS1 addressieren und mit nas2.cf.synology.me das NAS2.
Also bei mir funktioniert das so, um Docker-Dienste auf NAS2 zu erreichen. Für HyperBackup habe ich das nicht ausprobiert.
Hilfreich?
0
Cornelius Fischer
26.08.24
19:31
sudoRinger
Guter Hinweis! 🙏🏼
Bin vom Konzept her jetzt übergegangen das Quell-NAS per VPN mit dem Heim-LAN zu verbinden. Das funktioniert auch schonmal. Nur das Anmelden klappt weiterhin nicht. Greife jetzt direkt per IP Eingabe vom Quell zum Ziel-NAS zu. Weiterhin obige Fehlerauflistung.
Der Zugriff via VPN/IP sollte doch gehen, auch wenn im Heim-LAN zwei NAS stehen. Per IP adressiere ich ja nun direkt das Ziel-NAS. 🤷♂️
Hilfreich?
0
sudoRinger
26.08.24
19:39
Cornelius Fischer
Der Zugriff via VPN/IP sollte doch gehen, auch wenn im Heim-LAN zwei NAS stehen. Per IP adressiere ich ja nun direkt das Ziel-NAS. 🤷♂️
Gibt es getrennte IP-Bereiche für das Quell- und Zielnetzwerk? Statt VPN nutze ich die Zero Trust Netzwerke Tailscale und Twingate. Bei Tailscale hast Du dann eine IP in der Form 100.x.y.z, um das NAS.anzusprechen. Das funktioniert viel einfacher und problemloser als VPN.
Hilfreich?
0
Cornelius Fischer
26.08.24
19:45
sudoringer
Quelle: 192.168.1.x
Ziel: 192.168.2.x
Somit, ja IP-Range ist unterschiedlich.
Hab gerade noch geprüft ob DSM auf beiden Systemen aktuell ist. Das passt.
HyperBackup und HyperBackup Vault ist auf beiden Systemen auch aktuell.
Was ich noch nicht gemacht habe, ist das Quell-NAS neuzustarten. Das mache ich gleich noch. Vielleicht hängt da irgendetwas.
Hilfreich?
0
Cornelius Fischer
26.08.24
20:13
Okay, jetzt wirds strange. Hab gerade versucht von meinem eigenen lokalen NAS ein HyperBackup Task mit Ziel auf dem 2. NAS (von meinem Kollegen), welches ja im gleichen LAN steht zu erstellen.
Komme auch hier nicht durch die Anmeldung. Zwar kommt kein Fehler-PopUp (Screenshot oben), es kommt einfach garnichts. Ich klicke auf Anmelden, dann sehe ich für einen Bruchteil einer Sekunde eine "Wird geladen" Box und mehr passiert nicht. Ich komme schlicht nicht zu Feld für die Eingabe von User/Passwort. What the heck?
Da stimmt doch irgendetwas mit dem Ziel-NAS nicht. HyperBackup Vault hab ich bereits Re-Installiert. Updates sind alle gemacht. Neustart vor 30min erfolgt.
Hilfreich?
0
sudoRinger
26.08.24
20:19
Bei mir erscheint unter Servername der Name, der in DSM/Netzwerk/Allgemein eingetragen ist. Hast Du die Netzwerkschnittstelle (Gateway, DNS-Server) vom Gast-NAS für dein Netzwerk passend konfiguriert?
Hilfreich?
0
Cornelius Fischer
26.08.24
20:27
sudoRinger
Ich hab vielleicht das Problem gefunden. Auf dem NAS von meinem Kollegen ist das "neuste" DSM installiert. Einzig, heute kam ein grösseres Update, was noch nicht angezeigt wird. In den Release Notes unter "Fehlerbehebung" steht tatsächlich drin, dass ein Anmeldefehler bei HyperBackup gelöst wurde. Ich installiere entsprechend nun manuell auf die allerneuste Version. Mal schauen ob das wirklich das Problem ist.
Fix 14 - Fixed an issue where login might fail when creating backup or replication tasks to a remote target server via Snapshot Replication, Hyper Backup, or other packages.
Hilfreich?
0
Cornelius Fischer
26.08.24
21:13
Zu früh gefreut, Update auf DSM 7.2.2-72803 auf allen Systemen war leider nicht die Lösung. Da ich mich nichtmal von einem 2. NAS im gleichen LAN einen Backup Task erstellen kann (bleibe beim Anmelden hängen), mache ich jetzt mal ein Support Ticket bei Synology auf. 🤷♂️
Hilfreich?
0
Cornelius Fischer
26.08.24
22:39
Ein bisschen bin ich noch weiter gekommen.
Backup Plan vom lokalen NAS 1 (meins) zu lokalem NAS 2 (das vom Kollegen, welches Probleme macht), klappt. Blöder Pop-Up Blocker von Safari hat das Login blockiert. 🫣
Weiterhin bekomme ich aber stets die Fehlermeldung, wenn ich von einem der externen NAS ein Backup Plan erstellen möchte. Egal ob ich als Source das NAS von meinem Kollegen nehme (welches eine VPN Verbindung zu meinem LAN nutzt) oder eins meiner eigenen NAS aus meinem Büro, welche per Site-to-Site VPN auf das LAN zuhause zugreifen. Alle machen die gleiche Fehlermeldung (Screenshot weiter oben im Thread).
Von meinen NAS im Büro kann ich aber problemlos auf mein NAS zuhause Backup Pläne erstellen. Es will einfach nicht zu dem NAS von meinem Kollegen.
Hilfreich?
0
Cornelius Fischer
27.08.24
08:19
Neu Netzwerkkonfiguration:
NAS 2 (Backup Ziel des Kollegen) ist nun in einem isoliertem LAN mit IP Range 10.1.10.0/24. Dieses LAN hat nun keinen Zugriff mehr auf mein eigenes Home-LAN (192.168.2.0/24). Somit kann mein Site-to-Site zwischen meinem Office und Home-LAN nicht mehr reinfunken.
NAS 2 hat Internetzugriff. Login in DSM via Quick Connect funktioniert.
Source-NAS vom Kollegen ist per PPTP VPN mit dem isolierten LAN (10.1.10.0/24) bei mir zuhause verbunden.
Firewall seitig am Router gibt es derzeit keine speziellen Regeln für das 10.1.10.0/24 LAN
NAS 2 hat Firewall derzeit abgeschaltet
Source-NAS kann per VPN also direkt per IP auf das NAS 2 als Backup Ziel zugreifen.
Beim Anmeldeversuch in HyperBackup kommt aber weiterhin der Fehler, dass die Verbindung nicht hergestellt werden konnte mit der langen Liste an möglichen Fehlern.
Irgendjemand noch eine Idee was hier den Zugriff blockieren könnte? NAS 2 hat sein eigenes LAN und Internetverbindung, Source-NAS hat per VPN direkten Zugriff auf das LAN von NAS 2. Im LAN von NAS 2 befinden sich keine weiteren Geräte, einzig NAS 2 und das mit VPN verbundene Source-NAS.
Das isolierte LAN von NAS 2 hängt am Port 4 vom Synology Router und ist in den Netzwerkeinstellungen am Router genau so konfiguriert für Port 4.
Was ich heute noch Teste sobald ich im Office bin, mich vom Laptop her per VPN mit dem LAN von NAS-2 zu verbinden und dann dieses anzupingen.
Ich frage mich gerade ob es daran liegen könnte, das mein Modem allenfalls eine IPv4/IPv6 Internetverbindung bereitstellt. Am Synology Router im Netzwerk-Center im Status Tap kann ich jedenfalls eine IPv4 und eine IPv6 Verbindung sehen. Aber das dürfte doch bei einer VPN Verbindung keine Rolle spielen? 🧐
Hilfreich?
0
MikeMuc
27.08.24
09:20
Fangen wir ganz vorne an:
Kannst du das Problemnas anpingen und funktioniert die reguläre Anmeldung über die Weboberfläche aus deinem Netz? Kommst du per SMB oder AFP drauf?
Hilfreich?
0
sudoRinger
27.08.24
09:20
Cornelius Fischer
\Ich frage mich gerade ob es daran liegen könnte, das mein Modem allenfalls eine IPv4/IPv6 Internetverbindung bereitstellt. Am Synology Router im Netzwerk-Center im Status Tap kann ich jedenfalls eine IPv4 und eine IPv6 Verbindung sehen. Aber das dürfte doch bei einer VPN Verbindung keine Rolle spielen? 🧐
Den Satz verstehe ich nicht. Was möchtest Du noch sehen, IPv8?
Da ich die gleiche Kombination aus Router und zwei NAS habe, kann ich Dir anbieten, dass ich Screenshots vergleiche oder dir Screenshots von bestimmten Einstellungen zusende. Dann muss für die Öffentlichkeit nicht alles geschwärzt werden.
Wenn Du dir das Leben einfach machen willst, dann installiere Tailscale aus dem Paketzentrum auf dem Quell- und Zielserver. Die beiden Server sehen sich dann einander mit einer 100.x.y.z-IP.
Grundlage von Tailscale ist Wireguard.
Hilfreich?
0
Cornelius Fischer
27.08.24
09:56
Ich fühl mich gerade total unfähig, obwohl ich seit gut 10 Jahren mit Synology Servern arbeite und bereits mehrfach für mich und andere DiskStations aufgesetzt habe inkl. Backup Pläne auf extern stehende DiskStations..
MikeMuc
- Anpingen aus gleichen LAN funktioniert
- DSM Zugriff aus gleichen LAN und per VPN Verbindung funktioniert
- SMB Verbindung per VPN Funktioniert
- HyperBackup Sicherplan erstellen von einem 2. NAS im gleichen LAN wie das Problem-NAS funktioniert
Was nicht funktioniert ist das Erstellen eines Speicherplans, sobald die Quelle nicht mehr physisch im gleichen LAN steht. Egal ob der Zugriff über DDNS (mit allen Portfreigaben/Weiterleitungen am Router) oder per direkter VPN Verbindung vom Quell-NAS zum LAN des Ziel-NAS.
sudoRinger
War nur verwirrt wegen IPv4/v6 weil auf Facebook jemand geschrieben hat, dass dies eine Störquelle sein kann.
Auf dem Router sind aber entsprechende Firewall Regeln automatisch von RSM angelegt worden. Die heissen "compatibility v4" und compatibility v6" und lassen schlicht allen Traffic von LAN-Schnittstelle zu LAN-Schnittstelle durch.
Ich schick dir gerne per PN ein paar Screenshots zum Vergleichen. Ich bin ehrlich gesagt mittlerweile echt ratlos. Ich hab selber mehrere NAS und 2 LANs vollständig mit Synology Routern im Betrieb. Hab parallel noch auf 2 NAS die ich betreue geschaut wie ich es dort konfiguriert habe, zusätzlich abgeglichen wie ich bei meinen eigenen Backups konfiguriert habe und finde partout keinen Unterschied.
Irgendetwas auf dem Problem-NAS muss die Verbindung blockieren, sobald das Quell-NAS nicht physisch mit dem gleichen LAN vom Problem-NAS verbunden ist.
Hilfreich?
0
MikeMuc
27.08.24
14:15
Hmm, liest sich ja erstmal gut wenn das alles funktioniert. Mehr fällt mir dazu jetzt nicht ein, ein Netzwerkproblem sehe ich aktuell nicht
)
Hilfreich?
0
Cornelius Fischer
27.08.24
14:31
MikeMuc
Es bleibt wie verhext. Alle Zugriffe klappen, VPN klappt nur die Verbindung vom Source zum Remote NAS via HyperBackup (Anmeldung) will einfach nicht funktionieren. Ich bin mir mittlerweile zu 99.9% sicher, dass ich keine Konfigurationsfehler habe. sudoRinger hat in alle den Screenshots die ihm per PN geschickt habe auch nichts gesehen.
Hab mittlerweile ein Ticket bei Synology offen. Ich kann mir einfach nicht vorstellen, dass ich noch irgendwo etwas übersehen habe und hab schlicht die Vermutung, dass hier ein Bug in DSM vorhanden ist, der die Verbindung von Source zu Remote-NAS spezifisch für HyperBackup blockiert und die Anmeldung verunmöglicht.
Hilfreich?
0
rmayergfx
27.08.24
19:48
Oder es ist ein Port/Protokoll der benötigt wird und im Router blockiert ist oder nicht geroutet werden kann.
„Der Computer soll die Arbeit des Menschen erleichtern, nicht umgekehrt !“
Hilfreich?
-1
Cornelius Fischer
27.08.24
20:27
rmayergfx
Oder es ist ein Port/Protokoll der benötigt wird und im Router blockiert ist oder nicht geroutet werden kann.
Auch wenn das externe NAS per VPN mit dem LAN verbunden ist? 🤔 Damit müsste das externe NAS doch quasi wie ein lokales Gerät im LAN behandelt werden? 🧐
Da müsste ja dann ein klarer Hinweis dazu in den Anleitungen bei Synology sein. Hab da bis jetzt aber nichts gefunden.
Hilfreich?
0
rmayergfx
27.08.24
21:43
Gibt doch eine Übersicht von Synology welche Ports für welche Anwendung genutzt werden:
https://kb.synology.com/de-de/DSM/tutorial/What_network_ports_are_used_by_Synology_services
Zudem könntest du bestimmt in die Logs vom Router schauen, ob dort etwas weggeblockt wird oder ein Fehler auftaucht.
Nicht alles wird/kann per VPN geroutet werden. So gehen z.B. keine MagicPackets für WOL.
„Der Computer soll die Arbeit des Menschen erleichtern, nicht umgekehrt !“
Hilfreich?
0
Cornelius Fischer
27.08.24
22:26
Danke, die Liste ist ne super Referenz. 👍
HyperBackup Vault verwendet Port 6281, welcher auch per default bei einer neuen HyperBackup Aufgabe als Zielport angegeben ist beim Einrichtungsprozess. Port ist also sicher korrekt.
Wenn das Source-NAS per PPTP VPN mit dem LAN des Ziel-NAS verbunden ist, sollte der Traffic doch einfach durch gehen?
Protokolle auf dem Router hab ich schon mehrfach abgesucht, auch spezifisch mit den Uhrzeiten des Verbindungsversuchs für die HyperBackup Anmeldung vom Source-NAS zum Ziel-NAS. Nichts, kein Eintrag. Weder in den Protokollen vom Router, VPN Protokollen, Protokollen des Ziel-NAS und den Protokollen des Quell-NAS.
Quell-NAS verbindet sich mit PPTP VPN mit dem Router des Ziel-NAS. Die PPTP VPN Verbindung ist so konfiguriert, dass sie mit der Netzwerk-Schnittstelle des Ziel-NAS verbindet. Diese Methode wird im Netz immer wieder beschrieben für HyperBackup Konfigurationen und sollte somit eigentlich funktionieren.
In der FireWall am Router habe ich nichts spezifisch eingerichtet. Einzig eine Regeln, dass den Zugriff für PPTP zu SRM erlaubt. Das wurde automatisch vom Router so erstellt und dürfte die Freigabe sein, dass sich externe Geräte überhaupt mit PPTP am SRM vom Router authentifizieren.
Meines Wissens braucht es dann keine weiteren Freigaben in der Firewall vom Router als auch keine weiteren Portweiterleitungen am Router, oder liege ich da falsch?
NAT Pass-Through für PPTP ist am Router deaktiviert. Hab es aber Testweise auch mal aktiviert. Hat auch nicht geholfen um die Verbindung zwischen Quell-NAS und Ziel-NAS aufbauen zu können. Und so wie ich NAT Pass-Through verstehe, sollte das doch auch keinen Einfluss haben, wenn sich ein externer Client am Router mit VPN verbindet, oder doch? 🧐 Da finde ich die Synology SRM Hilfe nicht so hilfreich im Wording.
rmayergfx
Gibt doch eine Übersicht von Synology welche Ports für welche Anwendung genutzt werden:
https://kb.synology.com/de-de/DSM/tutorial/What_network_ports_are_used_by_Synology_services
Zudem könntest du bestimmt in die Logs vom Router schauen, ob dort etwas weggeblockt wird oder ein Fehler auftaucht.
Nicht alles wird/kann per VPN geroutet werden. So gehen z.B. keine MagicPackets für WOL.
Hilfreich?
0
rausche
28.08.24
08:46
Eventuell liegt es nicht an den verschiedenen getesteten Netzwerkkonfigurationen. Ich hatte auch mal das Problem das VPN zwischen beiden Standorten korrekt funktionierte aber trotzdem HyperBackup das Ziel nicht finden, bzw. sich nicht verbinden konnte. Bei mir lag es damals an den deaktivierten "admin" Konto. Erst als ich den "admin" wieder aktivierte und zur Identifizierung benutzt habe, funktionierte es.
Hilfreich?
0
Cornelius Fischer
28.08.24
09:10
rausche
Du meinst das "admin" Konto, welches per Default in DSM installiert ist?
Der Synology Support hat mittlerweile Zugriff auf beide Server zur Fernwartung erhalten. Bin gespannt was die rausfinden.
Edit: "admin" Konto auf Ziel-NAS aktiviert. Verbindung immer noch nicht möglich vom Source-NAS aus. Oder meinst du effektiv, dass auf dem Ziel-NAS auch mit dem "admin" bei dir eingeloggt werden musste? An sich bin ich mit einem Admin drin, allerdings nicht mit dem default "admin". Oder meinst du auf Source-NAS eben und dort "admin"? Auch auf dem Source bin ich mit einem Admin drin, aber nicht mit dem default "admin".
Hilfreich?
0
rausche
29.08.24
23:18
Ich meinte bei der Identifizierung im Hyperbackup auf dem enterten NAS.
Bei mir war es ein Rechteproblem was sich leider nur mit dem "admin" Konto beheben lies. Wenn es geht lass den "admin" lieber deaktiviert.
Hilfreich?
0
Cornelius Fischer
30.08.24
08:24
rausche
Das ist ja mein Problem, ich komme erst garnicht auf das PopUp, welches mir ermöglichst Benutzer/Passwort einzugeben. An Source NAS trage ich die IP (Verbindung erfolgt ja per VPN) zum Ziel-NAS ein und klicke unten auf Anmelden. Jetzt sollte eigentlich ein Login-Fenster kommen. Stattdessen bekomme ich die Meldung "Verbindung konnte nicht hergestellt werden". Irgendetwas blockiert also ganz grundsätzlich die Verbindung zum Ziel-NAS.
Screenshot der Fehlermeldung ist oben im Thread ersichtlich.
Hilfreich?
0
Cornelius Fischer
03.09.24
17:15
Finally, die Verbindung läuft und das 1. Backup kopiert.
Der Synology Support hat einiges getestet, die Lösung war aber am Schluss nicht der Vorschlag vom Support.
Vorschlag Support:
In den Einstellungen des VPN-Profil des Source-NAS die Option "Standard-Gateway auf Remote-Netzwerk verwenden". aktivieren und VPN Verbindung neu aufbauen. Dazu in den allgemeinen Einstellungen die Option "Mehrere Gateways verwenden" aktivieren.
Damit konnte ich mich einmalig anmelden. Jedoch hat das Source-NAS das Standard-Gateway bei mir immer wieder auf das lokale LAN gewechselt und die Verbindung zum Remote-NAS ging verloren.
Lösung:
VPN Profil OHNE die Option "Standard-Gateway auf Remote-Netzwerk verwenden" einrichten, jedoch "mehrere Gateways verwenden" in den allgemeinen Netzwerkeinstellungen aktivieren.
Anschliessend eine statische Route für die Netzwerk-Schnittestelle "VPN" einrichten zum VPN-Ziel LAN und in der statischen Route das VPN-Gateway vom Ziel-LAN (bei mir 10.1.10.145) als Gateway eingeben.
Zack, nun läufts.
Ich hab das mit der statischen Route am Anfang schonmal versucht, jedoch als Gateway wahrscheinlich 10.1.10.1 und nicht 10.1.10.145 eingegeben. Der VPN Server scheint sich im Ziel-LAN nicht mit dem Standard-Gateway 10.1.10.1 zu verbinden sondern eben mit der 10.1.10.145.
Das ganze hat mich einiges an Nerven gekostet, bin aber froh dass nun alles läuft und das mein Kumpel nun endlich seine Backups auf sein NAS in meinem Keller laufen lassen kann. 🥳
Hilfreich?
0
Kommentieren
Diese Diskussion ist bereits mehr als 3 Monate alt und kann daher nicht mehr kommentiert werden.
News zur Mac-Woche: MacBook Pro mit 24 GB RAM? ...
Gescheitert: iPhones von Robotern statt Arbeite...
Musikbranche verklagt KI-Anbieter
Mac ausschalten?
Vor 10 Jahren: 3 Milliarden für Beats
Qualitätsprobleme bei MacBook-Displays: Apple t...
Das MacBook Pro M4
Mac mini: Kontroverse Position des Einschalters...