Samba is for photos that leave the phone but stay in the house. Traffic is TCP 445, not HTTP. Azalea does not provide a NAS and does not proxy originals. You run Synology, TrueNAS, or a Debian share; the app writes originals there. Bundle net.duguying.photos. provider is samba. The Bucket field is the share name, not a friendly folder label. The engine does not connect when you tap save. The first list or write opens the session. A bad password shows up when you start a backup, not in the form.

Do not forward TCP 445 to the internet. This is a LAN backup, not a travel cloud. Use an object-storage profile on the road and Samba at home; multiple profiles are supported. English-language tests used a Synology DS220+ DSM 7.2.2 and also a vanilla Samba 4.17 share on Debian. Guest mode worked only when the server allowed it; DSM with “local users” rejected empty passwords even with guest=true.

What to put in the profile

Endpoint: host, 192.168.1.32 or nas.local, optional smb://. Prefer an IP unless Local Network is on. mDNS flakes on the lab router.
Bucket: share name. Lab share was photos.
AccessKey / SecretKey: NAS user / password. Secrets on iOS go in Keychain.
Root prefix: optional path inside the share.
Extra: domain, port (default 445), guest only if the server allows empty passwords.

There is no probe() capacity figure, so ETA cannot use “bytes free.” The app does not show free space. A full volume errors on write. Concurrency caps at 8. Writes use a same-directory temp plus rename; SMB rename cannot overwrite, so a replace deletes the target first. No presign_put.

Steps for a house NAS

On the NAS, create user album (or similar) with access to one share only. Guest off. SMB3. Wired 1 GbE to the NAS if you can; phones will still be on Wi-Fi.
iPhone: Settings → Azalea Photos → Local Network on, or *.local fails quietly. That is an Info.plist Local Network usage issue in the host app, not something the engine can fix after the fact. Install Azalea, Allow Full Access.
Cloud Album → Backup Storage → add Samba. Endpoint 192.168.1.32, bucket photos, user and password. Tap Test Connection if the build offers it; otherwise the first backup is the probe. Wrong share name fails then.
Android: same profile fields. Allow access to all. Automatic backup. On HyperOS, disable battery optimization for Azalea Photos or the Azalea backup notification outlives the worker.
Run until Pending is 0. Second phone: same endpoint, same share, Claim when historical indexes appear. Do not rename the iPhone folder in File Station; the Xiaomi claim will miss the physical path.
Spot-check HEIC and 4K from a laptop mount of the same share. Do not tidy names. Object keys carry a device dimension so two phones do not collide.

January–March 2026, DS220+ DSM 7.2.2, share photos, SMB3, NAS in a cabinet, Ethernet to the desk, phones on 5 GHz. iPhone 14 Pro wrote 9,023 items (~41.2 GB). Xiaomi 14 wrote 6,744 (~28.7 GB). Combined 15,767 items, 69.9 GB. Both can list the same library. Four failures were idle session drops, not a full volume; all retried. The iPhone failed nas.local until Local Network permission was granted. After that, 192.168.1.32 was more stable.

Xiaomi 14 HyperOS 2.0.5 kills background work aggressively. Resume was open the app. HEIC is 44% of the combined library, all from the iPhone. The Xiaomi side is mostly JPEG.

Give album that one share and nothing else. Renaming folders in File Station breaks a later claim. USB remains the travel option; see backup to USB. English S3 tests (us-west-2) are the hotel option; Chinese write-ups of the same method may mention COS Guangzhou.

Phones stay on Wi-Fi even when the NAS is wired. A 5 GHz hop plus SMB session setup is why a 1 GbE pack is not a desktop copy speed. Keep the iPhone awake for the first night; Local Network permission does not stop iOS from pausing a backgrounded app. On Android, Resume backup after every HyperOS kill is the expected loop, not a defect you can toggle away in Azalea. If DSM reports the volume filling, stop the job yourself — Azalea will only error on the write that does not fit.

One failure: guest=true on DSM local users

Empty password plus guest flag looks convenient. DSM rejected it. The profile saved. The backup failed on first I/O. Create a real user. The other lab scar is mDNS: nas.local without Local Network looks like a dead NAS. It was a permission. Four idle session drops on 1 GbE were retried; they were not a full volume. Because there is no free-space probe, a share that fills overnight fails mid-write — watch DSM storage, not Azalea’s missing disk meter.

FAQ

Is NAS backup phone photos the same as USB claim?

Same idea, different transport. USB uses .album/manifest.jsonl on a plug-in volume. Samba uses the share as the disk. Claim still matches keys. Favorites still will not cross to Android via local_identifier.

Should I use nas.local or an IP?

IP, unless you have confirmed Local Network and mDNS on your router. Lab router flaked. 192.168.1.32 held.

Can I use this on public Wi-Fi?

You should not expose SMB. Use S3/COS/OSS when you are away. Keep Samba on the LAN. Multiple profiles exist so you can switch.

Why did HyperOS stop the NAS job?

OEM battery policy. WorkManager is not stronger than HyperOS. Open Azalea. Resume backup. Take the app off optimization. Family case page: /en/cases/case-family-nas. Feature fields: /en/features/nas.

Where to download?

/en/download. Android permission and worker notes: Android original-quality auto backup.

Back up the camera roll to a NAS over Samba