Persze hogy van benne samba.
Egy idealis vilagban, nem SMB lenne benne, hanem valami nyitott protokoll, pl. NFS. Ott egy ilyen huzas, kb kizarolagosan az Apple hibaja lenne, mert a kotelezo dolgokat specifikaltan kellene implementalni, mig a nem kotelezoek megletere pedig nem lenne szabad alapozni. Az SMB sajna nem ilyen. Az AFP pedig, meginkabb nem az volt.
Amúgy NFS-en is lehet csatolni a synology megosztást (nekem proxmox alá úgy van a syno becsatolva), esetleg azt tényleg ki próbálhatod @solareclipse. Én még kivárok a frissítéssel 
NFS megosztast nem tudsz TM-nek kivalasztani. Max, kezzel emlekeim szerint. Tehat Felcsatolva a megosztast, majd felcsatolva a sparsebundlet. Viszont automatan ezt nem fogja csatolgatni, ha backupot kezdemenyezel.
1 kedvelés
Akkor kapufa 
Ez a konfig mukodik nalam, bar en meg nem frissitettem, nem tudom, macOS 26-al is megy-e.
[global]
fruit:aapl = yes
fruit:nfs_aces = yes
fruit:copyfile = yes
fruit:model = MacSamba
fruit:resource = xattr
fruit:metadata = stream
fruit:locking = netatalk
vfs objects = catia fruit streams_xattr
read only = No
logging = file
log file = /var/log/samba/log.%m
max log size = 1024
log level = 2
server string = NAS
multicast dns register = yes
client max protocol = default
client min protocol = SMB2_02
server min protocol = SMB2_02
socket options = TCP_NODELAY
aio read size = 65536
aio write size = 65536
guest ok = no
security = user
unix password sync = yes
[Time Machine]
comment = Time Machine
path = /storage/backup/timemachine/%U
available = yes
browseable = yes
writable = yes
fruit:locking = none
fruit:time machine = yes
Ubuntun a “samba” es “samba-vfs-modules” csomagok kellenek, illetve az “avahi-daemon” es “avahi-utils”, hogy az automatikus felderites is mukodjon.
A tuzfalon a 5353-as (Avahi) portot kell kinyitni, illetve ufw tuzfalon a Samba alkalmazast engedelyezni.
A felhasznalok jelszavat, sajnos nem veszi at a samba, meg nem jottem ra, azt hogyan lehetne megoldani, szoval mindegyik felhasznalohoz be kell allitani jelszot a szerveren:
smbpasswd
Az normalis, hogy nem veszi at… Mas fajta jelszo hasht hasznal a 2 vilag, igy nincs arra mod, ma mar, hogy az SMB klilenstol erkezo jelszoval ezt megcsinald. A multban volt arra opcio, hogy az SMB kliens nem hasznal titkositast, igy plain text kuldte el a jelszot, ilyenkor a Linux el tudta hashelni a jelszot, es ossze tudta vetni a lokalis adatbazisban levo hashelt jelszoval. Igy a jelszo 1 helyen volt tarolva, es a Windows iranyabol kezdemenyezett jelszovaltoztatas is at tudta allitani a Linux jelszot. De Vista ota talan, defaultbol mar encryptelt jelszot kuld a Windows, igy ezt ki kellett kapcsolni es talan 8.1-tol vagy 10-tol nincs mar lehetoseg nem encryptelt jelszokuldesre, igy ez a megoldas elhalt. A masik ut, egy pam modul volt, amivel a rendszer updatelni tudta a samba jelszot, amikor a linux jelszo megvaltozott, igy a rendszeren 2 helyen volt tarolva a jelszo, de legalabb a jelszo kozos volt. A Windows iranybol kezdemenyezett jelszovaltoztatas nem tudta megvaltoztatni onnantol a Linux jelszot, uj Samba user hozzaadasanal, pedig meg kellett valtoztatni a rendszerjelszot. Ez is megszunt kb 10 eve, mert folyamatosan biztonsagi “rest” jelentett, ugyanis tarolhattad akarmennyire biztonsagos modon a Linux jelszot ott, ahol taroltad, olyan hash megoldassal amivel taroltad, a szinkronban tartott jelszo miatt, ugyonez a jelszo szerepelt a Samba password allomanyaban is, abban a hash algoritmusban, amit az admin beallitott, mint legkorabbi kliens, ami tud csatlakozni a serverhez, a 2010-es evekre pedig egy MD4 hash visszafejtes sem volt nehez. Igy aztan ez is ki lett dobva, ma pedig lenyegeben, vagy eltero password allomanybol authentikal a Linux es a Samba, vagy egy kozos authentikacios szervert hasznal mind a ketto.
Szoval, ez direkt ilyen, mert ilyen tud lenni.
2 kedvelés
Koszonom a leirast, ezt nem tudtam
Igazabol ha az Ansible tudna Samba jelszot beallitani, azzal is elegedett lennek. 
Egy megoldás lenne: a MacOS Server alkalmazás LDAP szerverben tárolja a felhasználókat és a jelszavakat, de ezt sajnos nem sikerült reprodukálnom linux szerveren.
A netatalk tök jól működik az LDAP szerverrel, a Samba viszont elég egyedi architektúrát használ, próbáltam már sok féle .ldiff-et, nem sikerült működésre bírni. Feladtam, és smbpasswd-t használok, mint az ősemberek. 
Az igazság az, hogy én sem próbáltam meg beállítani még sambát saját magamnak. A cégnél van, de ott Active Directory van. Viszont linux oldali authnál fontos, hogy LDAPban legyen a usernek uid, uidnumber és gidnumber értékei. Ha ezek nincsenek, akkor nem működik linux oldalról az ldap auth. Nem tudom, hogy ezek be voltak-e állítva. Meg, mint ahogy Czo is írta pam kell hozzá + mi sssd-t használunk és fontos, hogy kikapcsolt nslcd mellett.
Nálam Tahoe frissítés után is megy a TM backup a syno-ra, DSM 7.1.1-42962 van fent nálam.
l hogyan állítod be 
Én most külső SSD-re mentek mint az állatok.
Nálad volt/van benne ékezetes karakter?
Nem módosítottam semmilyen beállításon, ment úgy ahogy a frissítés előtt volt. Engedélyezve van a afp illetve az alá beállítások vannak még engedélyezve:
Működik az LDAP auth, pam, netatalk OK. Csak a Sambával nem sikerül összehozni.
1 kedvelés