Samba ist für Fotos, die das Telefon verlassen, aber im Haus bleiben. Traffic ist TCP 445, nicht HTTP. Azalea stellt kein NAS und proxyt keine Originale. Sie betreiben Synology, TrueNAS oder einen Debian-Share; die App schreibt Originale dorthin. Bundle net.duguying.photos. provider ist samba. Das Feld Bucket ist der Share-Name, kein freundliches Ordnerlabel. Die Engine verbindet nicht beim Tippen auf Speichern. Die erste Liste oder der erste Write öffnet die Session. Ein schlechtes Passwort zeigt sich, wenn Sie ein Backup starten, nicht im Formular.

TCP 445 nicht ins Internet weiterleiten. Das ist ein LAN-Backup, keine Reise-Cloud. Unterwegs ein Objektspeicher-Profil und zu Hause Samba; mehrere Profile werden unterstützt. Englischsprachige Tests nutzten eine Synology DS220+ DSM 7.2.2 und auch einen Vanilla-Samba-4.17-Share auf Debian. Guest-Modus klappte nur, wenn der Server ihn erlaubte; DSM mit „lokalen Benutzern“ lehnte leere Passwörter auch mit guest=true ab.

Was ins Profil gehört

Endpoint: Host, 192.168.1.32 oder nas.local, optional smb://. Eine IP bevorzugen, außer Local Network ist an. mDNS flackert auf dem Labor-Router.
Bucket: Share-Name. Der Labor-Share war photos.
AccessKey / SecretKey: NAS-User / Passwort. Geheimnisse auf iOS liegen in der Keychain.
Root-Prefix: optionaler Pfad im Share.
Extra: Domain, Port (Standard 445), Guest nur, wenn der Server leere Passwörter erlaubt.

Es gibt keine probe()-Kapazitätszahl, also kann ETA nicht „Bytes frei“ nutzen. Die App zeigt keinen freien Speicher. Ein volles Volume meldet beim Schreiben einen Fehler. Concurrency deckelt bei 8. Writes nutzen ein Temp im selben Verzeichnis plus Rename; SMB-Rename kann nicht überschreiben, also löscht ein Replace das Ziel zuerst. Kein presign_put.

Schritte für ein Haus-NAS

Auf dem NAS User album (oder ähnlich) mit Zugriff auf nur einen Share anlegen. Guest aus. SMB3. Wenn möglich 1 GbE verdrahtet zum NAS; Telefone bleiben am Wi-Fi.
iPhone: Einstellungen → Azalea Photos → Local Network an, sonst scheitert *.local still. Das ist ein Info.plist-Local-Network-Usage-Thema in der Host-App, nichts, was die Engine nachträglich repariert. Azalea installieren, Allow Full Access.
Cloud Album → Backup Storage → Samba hinzufügen. Endpoint 192.168.1.32, Bucket photos, User und Passwort. Test Connection tippen, wenn der Build es bietet; sonst ist das erste Backup die Probe. Falscher Share-Name scheitert dann.
Android: dieselben Profilfelder. Allow access to all. Automatic backup. Auf HyperOS Akkuoptimierung für Azalea Photos aus, sonst überlebt die Benachrichtigung Azalea backup den Worker.
Laufen lassen, bis Pending 0 ist. Zweites Telefon: derselbe Endpoint, derselbe Share, Claim, wenn historische Indizes erscheinen. Den iPhone-Ordner in File Station nicht umbenennen; der Xiaomi-Claim verfehlt den physischen Pfad.
HEIC und 4K von einem Laptop-Mount desselben Shares stichproben. Namen nicht aufräumen. Object keys tragen eine Device-Dimension, damit zwei Telefone nicht kollidieren.

Januar–März 2026, DS220+ DSM 7.2.2, Share photos, SMB3, NAS im Schrank, Ethernet zum Schreibtisch, Telefone auf 5 GHz. iPhone 14 Pro schrieb 9.023 Elemente (~41,2 GB). Xiaomi 14 schrieb 6.744 (~28,7 GB). Zusammen 15.767 Elemente, 69,9 GB. Beide können dieselbe Bibliothek listen. Vier Fehler waren Idle-Session-Drops, kein volles Volume; alle retried. Das iPhone scheiterte an nas.local, bis Local-Network-Rechte gewährt waren. Danach war 192.168.1.32 stabiler.

Xiaomi 14 HyperOS 2.0.5 tötet Hintergrundarbeit aggressiv. Resume war die App öffnen. HEIC ist 44 % der kombinierten Bibliothek, alles vom iPhone. Die Xiaomi-Seite ist meist JPEG.

album nur diesen einen Share geben und sonst nichts. Ordner in File Station umzubenennen bricht einen späteren Claim. USB bleibt die Reiseoption; siehe Backup auf USB. Englische S3-Tests (us-west-2) sind die Hoteloption; chinesische Schreibweisen derselben Methode nennen oft COS Guangzhou.

Telefone bleiben am Wi-Fi, auch wenn das NAS verdrahtet ist. Ein 5-GHz-Hop plus SMB-Session-Setup ist, warum ein 1-GbE-Pack keine Desktop-Kopiergeschwindigkeit ist. Das iPhone in der ersten Nacht wach halten; Local-Network-Rechte halten iOS nicht davon ab, eine hintergründige App zu pausieren. Auf Android ist Resume backup nach jedem HyperOS-Kill die erwartete Schleife, kein Defekt, den Sie in Azalea wegschalten. Meldet DSM, dass das Volume volläuft, den Job selbst stoppen — Azalea meldet den Fehler erst beim Write, der nicht passt.

Ein Fehler: guest=true bei DSM-Lokalbenutzern

Leeres Passwort plus Guest-Flag wirkt bequem. DSM lehnte es ab. Das Profil speicherte. Das Backup scheiterte am ersten I/O. Einen echten User anlegen. Die andere Labornarbe ist mDNS: nas.local ohne Local Network wirkt wie ein totes NAS. Es war ein Recht. Vier Idle-Session-Drops auf 1 GbE wurden retried; sie waren kein volles Volume. Weil es keine Freispeicher-Probe gibt, scheitert ein Share, der über Nacht vollläuft, mitten im Write — DSM-Speicher beobachten, nicht Azaleas fehlendes Plattenmeter.

FAQ

Ist NAS Backup Handyfotos dasselbe wie USB-Claim?

Dieselbe Idee, anderer Transport. USB nutzt .album/manifest.jsonl auf einem Steck-Volume. Samba nutzt den Share als Platte. Claim matcht weiterhin Keys. Favoriten kreuzen weiterhin nicht über local_identifier nach Android.

Soll ich nas.local oder eine IP nutzen?

IP, außer Sie haben Local Network und mDNS auf Ihrem Router bestätigt. Der Labor-Router flackerte. 192.168.1.32 hielt.

Kann ich das im öffentlichen Wi-Fi nutzen?

SMB sollten Sie nicht exponieren. Unterwegs S3/COS/OSS. Samba im LAN lassen. Mehrere Profile existieren, damit Sie wechseln können.

Warum hat HyperOS den NAS-Job gestoppt?

OEM-Akkupolitik. WorkManager ist nicht stärker als HyperOS. Azalea öffnen. Resume backup. Die App von der Optimierung nehmen. Familienfall-Seite: /de/cases/case-family-nas. Feature-Felder: /de/features/nas.

Wo herunterladen?

/de/download. Android-Rechte und Worker-Notizen: Android-Autobackup in Originalqualität.

Kamerarolle per Samba auf ein NAS sichern