macOS Sonoma Time Machine Backup auf NAS wird immer wieder übersprungen?

[RealRusty]

Dann hätte Apple doch etwas darüber schreiben müssen.

Wohl kaum. Die können ja unmöglich die ganze Welt gegen ihr macOS testen. Aber ja, manchmal bei Problemen gibt es Hinweise mal von dieser mal von anderer Stelle. Wenn es eine WD NAS ist (kann man da überhaupt NAS zu sagen bei dem Teil?) würde ich mal bei WD suchen ....

 

[win2mac]

Nein ich habe das NAS mit dem Mac vom Mac aus verbunden und kopiere riesen Dateien darauf und kopiere sie nachher zurück.

warum schreibst du es dann anders?

 

[carsten_h]

kann man da überhaupt NAS zu sagen bei dem Teil?

Ja sicher. Es ist ein Netwark Attached Storage. Nicht mehr und nicht weniger. Es stellt per SMB Freigaben zur Verfügung und kann darauf Daten ablegen und wieder hergeben. Perfekt für genau diese Aufgabe.

 

[carsten_h]

warum schreibst du es dann anders?

Ja, das war blöd formuliert. Aber wer baut denn vom NAS zu seinem Mac eine verbindung auf. ?-)

 

[RealRusty]

Ja sicher. Es ist ein Netwark Attached Storage. Nicht mehr und nicht weniger. Es stellt per SMB Freigaben zur Verfügung und kann darauf Daten ablegen und wieder hergeben. Perfekt für genau diese Aufgabe.

Schon klar. So war das nicht gemeint aber die Dinger haben keinen guten Ruf und da würde ich wirklich mal nach Info bei WD zu macOS suchen und drücke die Daumen!

 

[carsten_h]

Ich habe mir jetzt einmal angesehen wie samba auf der WD MyCloud konfiguriert ist:

smb.conf

[global]
  workgroup = WORKGROUP
  realm = WORKGROUP
  netbios name = WDMyCloud
  server string = WD My Cloud

  include = /etc/samba/smb-global.conf
  include = /etc/samba/smb-global_veto.conf
  include = /etc/samba/overall_share

 
  include = /etc/samba/tm_config.conf

smb-global.conf

[global]
  load printers = no
  printable = no
  log file = /var/log/samba/log.smbd
  max log size = 50
  deadtime = 30
  enable core files = no
  security = user
  encrypt passwords = yes
  passdb backend = smbpasswd:/etc/samba/smbpasswd
  create mask = 0775
  force create mode = 0775
  directory mask = 0775
  force directory mode = 0775
  local master = yes
  domain master = no
  preferred master = auto
  os level = 5
  use sendfile = yes
  dns proxy = no
  idmap uid = 10000-65000
  idmap gid = 10000-65000
  admin users =
  null passwords = yes
  map to guest = bad user
  guest account = nobody
  force group = share
  unix extensions = no
  acl check permissions = false
  browseable = yes
  syslog = 1
  socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=2048000 SO_SNDBUF=2048000
  min receivefile size = 16384
  smb encrypt = disabled
  writeable = yes
  delete veto files = true
 
  ## Note: be careful when setting "dos filemode=yes".  We have seen where Samba does not
  ## handle this properly (and crashes) upon a rename of a file where the authenticated user is not the owner.
  ##dos filemode = yes
 
  max protocol = SMB3
  smb2 leases = yes
  fruit:copyfile= yes

overall_share

[TimeMachineBackup]
comment = TimeMachine
path = /shares/TimeMachineBackup
browseable = yes
public = yes
available = yes
oplocks = yes
map archive = no
guest ok = yes
writable = yes
# !!properties = "remote_access"

tm_config.conf

[TimeMachineBackup]
  strict sync = yes
  vfs object = catia fruit streams_xattr
  durable handles = yes
  kernel oplocks = no
  kernel share modes = no
  posix locking = no
  inherit acls = yes
  max share size = 3801345
  drive cache flush = yes

Vielleicht kann sich ja ein samba-Guru darüber hermachen.

 

[carsten_h]

Moin!

Ich habe jetzt einmal auf dem NAS direkt das sparsebundle gelöscht. Dann habe ich den Trick für WD angewendet, damit auch SMB benutzt wird.
Man muß im Finder die Time Machine Freigabe mit smb://wdmycloud.local/TimeMachineBackup als Gast mounten und dann die Freigabe auswählen und auf jeden Fall als "Gast" wählen. Damit wird jetzt ein neues sparsebundle angelegt.

Wichtig ist, daß man die richtige Freigabe in der Liste von Time Machine wählt und zwar die, bei der "wdmycloud.local" komplett klein geschrieben ist. Nicht:

denn das ist die AFP-Freigabe.

Mal sehen wie lange es jetzt hält.

 

[picollo]

Ich bin kein Samba-Guru oder -Experte. In meiner smb.conf auf meinem Raspberry Pi sind für Time Machine noch folgende Einträge zusätzlich drin:

[backups]
...
fruit:time machine = yes
fruit:aapl = yes
ea support = yes
spotlight = yes
...

 

[picollo]

Ich glaube nicht.

Doch, ich hatte sie selbst.

 

[carsten_h]

ich hatte sie selbst

Die mit der v4?

 

[picollo]

Schon lange weg.

 

[carsten_h]

Das sind die, die von WD abgekündigt wurden weil sie keine Updates mehr bekommen. Das ist mir aber egal, da sie nur im Heimnetz und nur für den Mac zuständig ist.

 

[RealRusty]

Das sind die, die von WD abgekündigt wurden weil sie keine Updates mehr bekommen. Das ist mir aber egal, da sie nur im Heimnetz und nur für den Mac zuständig ist.

Egal bis zu dem Zeitpunkt wo ein Update für neue macOSs notwendig werden?

 

[carsten_h]

Ich glaube (ja ich bin sehr gläubig) immer noch an ein Problem bei Apple, da es das gleiche Problem schon einmal vor Jahren gab. Es war in beiden Fällen das selbe NAS mit derselben Firmware.
Zum anderen sind in den letzten Jahren so gut wie alle Probleme, die ich hier hatte, auf Apple zurückzuführen und daher muß es auch diesmal Apple sein.

Apple schiebt schließlich auch immer meine Laufwerksicons über den Desktop ohne das jemand da Hand anlegt. Das hängt alles zusammen!

Ich habe gerade eine Möglichkeit herausgefunden wie man sieht mit welchen Protokoll sich ein Client per Samba verbindet.

Man muß nur in der Konfiguration die Logdateien speziell formatieren:

log file = /var/log/samba/log_%m_%a_%R

>From the man pages:

%m - netbios name
%a - machine architecture (note that MacOSX10.8 sometimes reports
"Samba", sometimes "OSX", 10.9 and 10.10 report "Vista")
%R - protocol level

Dadurch sieht man dann im Logdateinamen welches Protokoll der jeweilige Client benutzt hat. Lustiger Trick.

 

[lisanet]

Die smb.conf ist, naja, ungewöhnlich, (was einige Angaben betrifft) als auch potentiell fehleranfällig (was das vfs object fruit betrifft)

Das vfs fruit object mussbei allen shares vorhanden sein. macOS nimmt das 1. share das es findet und sieht quasi dort nach, ob fruit enthalten sit. Falls nein, wird es komplett deaktivert von sambe. Dies kann dann eben zur Folge haben, dass TimeMachine und/oder macOS nicht mehr richtig mit dem share umgehen können.

Die Entwickler des vfs objects empfehlen daher dringend, fruit bei allen shares zu aktivieren.

Aber erst zwei Bittem beovr ich hier weiter was schreibe.

Wenn du dich auf dem Teil in eine Konsole einloggen kannst, mach dort bitte mal

testparm -V

so sieht man die samba Version. Und dann

testparm -s

das gibt die smb.conf aus in konsolidierter Form, ohne default-Wert und sauber strukturiert. Bitte poste beides hier. Dann schaue ich mal, ob ich was sehe. Auf alle Fälle ist das mit fruit möglicherweise ein Grund. Es sind aber auch andere Parameter, welche die maOS Kompatibilität deutlich verbessern nicht enthalten.

Meine Erfahrung zeigt, auch wenn du der gegenteiligen Ansicht bist, dass die Konfiguration der diversen NAS und samba selbst oft die Ursache sind, nicht Apple.

Der Grund liegt einfach darin, dass samba mit dem Ziel entwickelt wurde, vollkommen kompatibel zu Windows Server zu sein, was sie auch hin krigen. Ebenso wird die Konfig der NAS regelmäßig auf Windows hin getrimmt. Und dann gibt es halt noch so ein paar Nettigkeiten, die man nur entweder pro Windows oder pro macOS lösen kann. Eine Seite muss ins Gras beißen. Und es sind auch noch zwein kleinere Ungereimtheiten bzw. Fehler im code von fruit. (ich habe das gepacht, aber noch nicht upstream gemeldet)

 

[lisanet]

ach ja, der Rest ist aber schon ok, so von wegen genügend Platz, kein Quota, kein initial zu großes Quota und dann nachträglich sonstige Dateien drauf kopiert?

Wenn es eine Zeit lang läuft und dann übersprungen wird, könnte so ein Quota-Problem vorliegen. Wenn man TimeMachine so einrichten muss wie du es beschrieben hast (was definitiv nicht der Weg ist, der automatisch vorgeschlagen würde, wenn das NAS korrekt konfiguriert wäre), und du kein explizites Quota angelegt hast (wird meist vergessen) dann nimmt sich TimeMachine die gesamte Kapazität des Volumes, auf dem das share liegt. Es wird ja so von samba zurück gemeldet. Wenn du dann andere Daten drauf kopierst (auch in ein anderes share), dann kann genau das passieren.

 

[carsten_h]

Danke für die Antwort!

Die smb.conf ist, naja, ungewöhnlich

Die entstammt der Feder von WD, was die sich aus den Fingern saugen kann ich so nicht beeinflussen. .-)

so sieht man die samba Version

WDMyCloud:~# testparm -V
Version 3.6.6

das gibt die smb.conf aus in konsolidierter Form

testparm -s
Load smb config files from /etc/samba/smb.conf
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
WARNING: The "idmap uid" option is deprecated
WARNING: The "idmap gid" option is deprecated
WARNING: The "null passwords" option is deprecated
WARNING: Ignoring invalid value 'SMB3' for parameter 'max protocol'
Unknown parameter encountered: "smb2 leases"
Ignoring unknown parameter "smb2 leases"
Processing section "[TimeMachineBackup]"
Processing section "[TimeMachineBackup]"
Unknown parameter encountered: "durable handles"
Ignoring unknown parameter "durable handles"
Global parameter kernel oplocks found in service section!
Unknown parameter encountered: "kernel share modes"
Ignoring unknown parameter "kernel share modes"
Unknown parameter encountered: "max share size"
Ignoring unknown parameter "max share size"
Unknown parameter encountered: "drive cache flush"
Ignoring unknown parameter "drive cache flush"
Loaded services file OK.
WARNING: cache directory /var/cache/samba should have permissions 0755 for browsing to work
WARNING: You have some share names that are longer than 12 characters.
These may not be accessible to some older clients.
(Eg. Windows9x, WindowsMe, and smbclient prior to Samba 3.0.)
Server role: ROLE_STANDALONE
[global]
    realm = WORKGROUP
    server string = WD My Cloud
    map to guest = Bad User
    null passwords = Yes
    passdb backend = smbpasswd:/etc/samba/smbpasswd
    log file = /var/log/samba/log_%m_%a_%R
    max log size = 50
    enable core files = No
    min receivefile size = 16384
    unix extensions = No
    deadtime = 30
    socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=2048000 SO_SNDBUF=2048000
    load printers = No
    os level = 5
    preferred master = Auto
    domain master = No
    dns proxy = No
    fruit:copyfile = yes
    idmap config * : range = 10000-65000
    idmap config * : backend = tdb
    force group = share
    read only = No
    acl check permissions = No
    create mask = 0775
    force create mode = 0775
    directory mask = 0775
    force directory mode = 0775
    smb encrypt = No
    use sendfile = Yes
    delete veto files = Yes
    veto files = /.nflc_data/.wdmc/.twonky/

[TimeMachineBackup]
    comment = TimeMachine
    path = /shares/TimeMachineBackup
    inherit acls = Yes
    guest ok = Yes
    strict sync = Yes
    map archive = No
    posix locking = No
    vfs objects = catia, fruit, streams_xattr

Die extra Freigaben habe ich gelöscht, da die hier ja keine Auswirkungen haben.

Meine Erfahrung zeigt, auch wenn du der gegenteiligen Ansicht bist, dass die Konfiguration der diversen NAS und samba selbst oft die Ursache sind, nicht Apple.

Meine Erfahrung bei der Fehlersuche in fremder Software, mit der ich mich so ca. seit 1991 beschäftige, ist eben die, daß der fehler normalerweise in dem Teil steckt, der gerade geändert wurde, nicht in dem, der schon jahrelang problemlos läuft.
Natürlich gibt es auch Fälle, bei denen erst ein Bugfix an der einen Stelle einen Bug an anderer Stelle zutage fördert, das will ich nicht gänzlich ausschließen. Allerdings hat die Software von Apple in den letzten Jahren zwar immer mehr Features aber dummerweise werden Bugs in den alten Teilen nicht mehr behoben und es kommen immer neue dazu. Alle zwei Jahre eine neue Version würde völlig reichen.

ich habe das gepacht, aber noch nicht upstream gemeldet

An welchem Code hast Du noch nicht etwas gepatcht? Für dieses NAS kommt aber jede Hilfe zu spät, es wird keine neue Firmware mehr geben.

so von wegen genügend Platz, kein Quota, kein initial zu großes Quota und dann nachträglich sonstige Dateien drauf kopiert?

Ja, es sind 4TB Platz für Time Machine, von denen jetzt erst ganze 600 GB belegt sind (das initiale Backup läuft noch 4 Stunden, vor drei Stunden waren es noch fünf Stunden). Ich kann auch erst nach dem Backup irgendetwas testen, da ich den smbd nicht in der Zeit neu starten möchte.

könnte so ein Quota-Problem vorliegen

Nein, da waren noch ca. 2,5 TB frei.

Wenn man TimeMachine so einrichten muss wie du es beschrieben hast (was definitiv nicht der Weg ist, der automatisch vorgeschlagen würde, wenn das NAS korrekt konfiguriert wäre)

Es geht dabei nur darum, daß man das NAS per smb und nicht per afp verbunden bekommt. Denn für afp gibt es keinen Schalter. Sicher könnte ich inzwischen einfach die Konfiguration auf dem NAS ändern, da es ja sowieso kein Update mehr gibt, das dann wieder alles überschreiben würde.

Wenn du dann andere Daten drauf kopierst (auch in ein anderes share), dann kann genau das passieren

Während ein Backup mit Time Machine lief, habe ich da keine anderen Backups drauf gemacht. Es war wirklich genug Platz vorhanden.

Aber erst zwei Bittem beovr ich hier weiter was schreibe.

Vielen Dank dafür!

 

[lisanet]

WDMyCloud:~# testparm -V
Version 3.6.6

puuh, das ist ja eine extrem alte samba Version. Die stammt aus 2012. Da kann ich dir nicht weiter helfen.

Mit samba 4.x (ich meine 4.2+) wurde das vfs object fruit ausgiebig verändert und für die speziellen Anforderungen von TimeMachine angepasst. Das ist jetzt aber auch schon etliche Jahre her, so in Richtung 2016/2017.

Die extra Freigaben habe ich gelöscht, da die hier ja keine Auswirkungen haben.

doch, die hätten Auswirkungen, da wie gesagt, das erste share bestimmt, ob fruit geladen respektive verwendet wird oder nicht.

Meine Erfahrung bei der Fehlersuche in fremder Software, mit der ich mich so ca. seit 1991 beschäftige, ist eben die, daß der fehler normalerweise in dem Teil steckt, der gerade geändert wurde, nicht in dem, der schon jahrelang problemlos läuft.

Nee, auch wenn es naheliegend ist.

Wenn ein korrespondierender Teil einer Software weiter entwickelt wird, hier macOS, der andere Teil aber auf uraltem Stand stehen bleibt, dann ist das eher Sache der Software, die endlich mal aktualisiert gehört. Ganz konkret hat Apple mit TimeMachine einige sehr sinnvolle Ergänzungen vorgenommen, die u.a. dafür sorgen, dass jedes Schreiben bestätigt wird. Alte Samba-Versionen können das nicht. Das wurde erst eben mit 4.2+ eingeführt und auch seither regelmäßig ergänzt. Seit dieser Zeit ist auch an samba so einiges an Fehlern behoben worden, die mit genau diesem vfs object zu tun haben.

Natürlich gibt es auch Fälle, bei denen erst ein Bugfix an der einen Stelle einen Bug an anderer Stelle zutage fördert, das will ich nicht gänzlich ausschließen.

Nein, es geht nicht darum, dass Apple einen Bug gefixt hätte, sondern dass samba eine ganze Zeit gebraucht hat, um überhaupt mehr und besser kompatibel mit TimeMachine zu werden und die Unzulänglichkeiten im Modul verringert hat.

Allerdings hat die Software von Apple in den letzten Jahren zwar immer mehr Features aber dummerweise werden Bugs in den alten Teilen nicht mehr behoben und es kommen immer neue dazu. Alle zwei Jahre eine neue Version würde völlig reichen.

Das hat mit dem Turnus rein gar nichts zu tun. SnowLeopard war jahrelang auf dem Markt, aber die Implementierung von TimeMachine war damals ein Graus.

Es geht dabei nur darum, daß man das NAS per smb und nicht per afp verbunden bekommt. Denn für afp gibt es keinen Schalter. Sicher könnte ich inzwischen einfach die Konfiguration auf dem NAS ändern, da es ja sowieso kein Update mehr gibt, das dann wieder alles überschreiben würde.

Wiederum: nee, die Art deiner Einrichtung ist seitens WD in keinster Weise an den Mac angepasst. Das erkennt man daran, dass du das share manuell erst mounten musst.

Wäre es korrekt konfiguriert mit Bonjour für smb und korrektem txt-record in der Bonjour-Announce, da könntest du unter macOS einfach die Systemeinstellungen zu TimeMachine öffnen und auf das + Symbol klicken und schon würde das TimeMachine-Share erscheinen. Nix mit manuellem mounten oder gar mit IP-Adresse rum hantieren und irgendwelche Syntax beachten, um das share zu finden.

Unter Sonoma könntest du da sogar ein Quota festlegen. Da dies aber alles nicht geht.... ist das keine macOS kompatible Konfiguration des NAS insgesamt. Ist leider sehr oft anzutreffen. Warum habe ich ja schon geschrieben: Windows geht den Herstellern vor. Da interessiert die eine user-freundliche Einrichtung unter macOS nicht.

Vielen Dank dafür!

Wie eingangs erwähnt: Die Software auf dem NAS ist uralt. Da wird TimeMachine nie wirklich verlässlich mit smb laufen. Da kann ich dir nicht helfen.

 

[carsten_h]

Da kann ich dir nicht weiter helfen.

Ok. Sehr Schade!
In der Zwischenzeit habe ich ein paar Dinge zu dem NAS gefunden. Zum einen ein Samba 4, das aber wohl aus Oktober 2014 stammt. Das dürfte dann auch zu alt sein.
Außerdem gibt es ein normales Debian Jessie, was natürlich auch schon einige Jahre auf dem Buckel hat.
Ein DSM 5 oder 6 gibt es auch, aber eben auch von 2015.
Oder ein OMV würde es auch geben, das würde aber auf dem Debian oben aufsetzen.

die hätten Auswirkungen

Diese beiden stehen noch vor TimeMachineBackup:

[Public]
    comment = Public
    path = /shares/Public
    guest ok = Yes
    map archive = No

[SmartWare]
    comment = SmartWare
    path = /shares/SmartWare
    guest ok = Yes
    map readonly = no

Das wurde erst eben mit 4.2+ eingeführt und auch seither regelmäßig ergänzt. Seit dieser Zeit ist auch an samba so einiges an Fehlern behoben worden, die mit genau diesem vfs object zu tun haben.

Ok. Sehr blöd.

Wäre es korrekt konfiguriert mit Bonjour für smb und korrektem txt-record in der Bonjour-Announce, da könntest du unter macOS einfach die Systemeinstellungen zu TimeMachine öffnen und auf das + Symbol klicken und schon würde das TimeMachine-Share erscheinen.

WD hat das eben wohl nur für AFP eingebaut. Wobei AFP eigentlich ja seit 2010 tot ist, oder?

Windows geht den Herstellern vor. Da interessiert die eine user-freundliche Einrichtung unter macOS nicht.

Schon klar.

Da wird TimeMachine nie wirklich verlässlich mit smb laufen.

Einige Jahre lang hat es ja wunderbar geklappt.

Da kann ich dir nicht helfen.

Danke trotzdem für die Mühe das anzusehen!

Die 6TB Platte im NAS hat zwar auch schon ihr alter, ist aber SMART-mäßig top in Ordnung. Ich könnte sie ausbauen und an etwas moderneres hängen. Ich muß mal sehen, ob sie extern am QNAP NAS für Time Machine benutzt werden kann.
Am Proxmox Server würde es auch gehen, ich will aber nicht so ein lautes Ding auf dem Schreibtisch, wo der Proxmox Server neben dem mini steht. Der muß auch da bleiben, da dort meine USB Lautsprecher für die Musikbeschallung hier am Mac angeschlossen sind.
Ich hatte gerade zum Test einmal einen Pi 4 (eigentlich wollte ich die ja alle durch den Proxmox ersetzen) mit Proxmox Backup Server installiert, da könnte die Platte auch dran. Nur sollte der PBS eigentlich zeitgesteuert an und ausgeschaltet werden, da das Backup nur zu einer bestimmten Zeit laufen würde. Das geht bei Time Machine ja nicht so gut.
Träume und Wünsche halt...

Das NAS hat jetzt das erste Backup um 1:30 fertiggestellt und es wurd das letzte Backup um 5:47 gemacht. Die direkte Platte hat um 4:53 eine Sicherung durchgeführt. Es läuft also bisher durch.

 

[Stargate]

Dann hätte Apple doch etwas darüber schreiben müssen.

Da wirst du vermutlich bei Apple noch einige Jahrzehnte warten dürfen, so ausführlich wie sonst alles andere auch beschrieben wird.
Es gibt Dinge die den Nutzer einfach nicht zu Interessieren haben.