Mac UTF-8 a Samba s vfs_fruit

[kutildomaci]

Před časem jsem narazil na ošklivost ve Finderu, který nezobrazuje soubory, pokud jejich název obsahuje složené UTF-8 znaky, tj. nikoli znak s diakritikou (zakódované do dvou bytů), ale znak + znak diakritiky (zakódované do 3 bytů).

Stává se mi, že uživatelé z Windows uloží soubory, které obsahují v názvu jednou tak, podruhé jinak zakódované znaky. V Linuxu se mi pochopitelně obojí zobrazuje nerozlišitelně stejně, dokud jsem nenechal název převést na hexadecimální čísla. K odhalení může pomoct Putty, který za určitých okolností zobrazuje složené znaky špatně.

Četnost s jakou Windows něco takového provedou je nezanedbatelná. Možná každý desátý soubor? Nepodařilo se mi vypozorovat jestli to jsou názvy, které uživatel vytvoří zkopírováním odněkud, nebo naklepe na klávesnici, nebo jestli to je specificky častější pro určitý software (stává se to u souborů s MS Office).

Nějak se mi to podařilo vyřešit pomocí vfs_fruit v kombinaci s mangled names (vypne překódování názvů do zkráceného názvu pouze z osmi znaků ASCII) a v kombinaci s unix charset a display charset, viz relevantní kousek konfigurace.

Modul catia je dle manuálu nutný pro volbu fruit:encoding = native.

Kód: [Vybrat]

        unix charset = UTF-8
        display charset = UTF-8
...
        vfs object = recycle fruit catia streams_xattr

        fruit:encoding = native
        fruit:resource = file
        fruit:posix_rename = yes
        fruit:veto_appledouble = yes
        fruit:nfs_aces = no
        fruit:wipe_intentionally_left_blank_rfork = true

        mangled names = no
Následně v každém sharu mám zapnuto ve shodě s globálním nastavením (kdesi psali, že to je potřeba):

Kód: [Vybrat]

        vfs object = recycle fruit catia streams_xattr
Nejsem si jistý volbou fruit:encoding = native vs private. Pochopil jsem, že jde o překódovávání nepovolených znaků do privátního rozahu UTF-8, ale jakých přesně znaků? Týká se to i složených znaků s diakritikou? Nebo jen znaků, které nejsou povolené na unixlike systémech, ale na Windows nevadí? Manuál mi připadá neúplný.

A která z voleb vlastně zajišťuje překódování složených znaků? Jsou místa, kde vfs_fruit nemám a MACkaři mi problémy nehlásili.

https://www.samba.org/samba/docs/current/man-html/vfs_fruit.8.html

Problém je, že když jsem fruit:encoding nastavil na private, tak začal padat Finder při pokusu o vstup do některých složek s diakritikou v názvu. Pád Finderu se projeví tak, že krátce po otevření složky (1s?) se zavřou všechna okna Finderu a odpojí se od Samby. Uživatel se pak musí znovu přihlásit.

Jako upřímně - mě to přijde jako dlouhodobě neřešená chyba MAC OSX a ne problém, který by se měl řešit na Sambě. Ale protože od Apple řešení očekávat nelze (dohledal jsem diskuze i 10 let staré, kde měl kdosi podobný problém), hledám rovnák na vohejbák pomocí nastavení Samby.

Jakou s tímto máte zkušenost?

Nepřipadá mi správné uživatelům radit, aby diakritiku v názvech přestali používat, jako to bývalo běžné v dobách DOSu a W9x.

[Reklama]

[jjrsk]

https://wiki.samba.org/index.php/Configure_Samba_to_Work_Better_with_Mac_OS_X

Tuhle to maji ponekud jinak nez to mas ty.

S vecma od jabka je to easy, proste nefungujou (resim s dodavatelem, ze jablecny kramy se neumej prihlasit domenovym uctem k firemnimu webu, cokoli jinyho funguje). Opakovane resim problemy s certifikatama, vpnkama ... atd atd.

A rekni uzivatelum at diaktiriku (nejen v nazvech) nepouzivaj .

[kutildomaci]

Tuhle to maji ponekud jinak nez to mas ty. https://wiki.samba.org/index.php/Configure_Samba_to_Work_Better_with_Mac_OS_X

To mě nepřekvapuje. Na mnoha místech to mají trochu jinak.

Mě by víc zajímalo, co konkrétně mám špatně, nebo co se vám (zdejším diskutujícím) osvědčilo / neosvědčilo. A pokud to bylo problematické, jak a proč? (pokud možno)

Vím, že fruit:nfs_aces = no je nezbytné k tomu, aby fungovala vynucená práva pomocí create mask, directory mask... to mám stejně.

fruit:metadata = stream jsem byl nucen přidat, protože selhávání Finderu bylo ve skutečnosti způsobeno pádem vfs_fruit a tedy odpojením MACku od Samby. Jestli to pomůže dlouhodobě zatím nevím. Proč k pádu vfs_fruit docházelo taky nevím, jen to, že se pád zapsal do logu Samby.

fruit:model = MacSamba je default volba, netuším, proč bych se měl obtěžovat to tam vůbec dávat.

fruit:posix_rename = yes máme shodné...

fruit:delete_empty_adfiles = yes jsem zakomentoval, protože nevidím přínos. Zatím.

Verze mé Samby je 4.17.12-Debian - tj. to, co je aktuální v aktualizovaném Debian 12.

[ja.]

Ste si istí, že nefungujú práve zložené UTF-8 znaky?

MacOS totiž vyžaduje v názvoch súborov NFD UTF-8 (pozri https://unicode.org/reports/tr15/), čo sú práve tie zložené. Neurobíme s tým nič, je to tak už od MacOS 10.0.

Linuxu je to naopak jedno, názov súborov je octet-stream, čo zase má za následok, že môžu v adresári existovať dva rozličné súbory, ktorých názov sa používateľovi zobrazujú rovnako.

U nás riešime problém, že používateľ si nevie otvoriť súbor s diakritikou tak, že používatelia majú prístup cez Synology Drive, kde si ho vedia premenovať. Čo sme vysledovali, tak problém vyzerá byť špecifický pre konkrétne aplikácie, stáva sa to napríklad s Windows verziou Wordu, kde potom používalia Mac majú smolu.

Synology SMB (aktuálne samba 4.15.13) vôbec nepoužíva vfs_fruit. Pre Mac maximálne svoj proprietárny modul syno catia, čo vyzerá byť fork vfs_catia. V dnešnej dobe používať vfs_fruit môže byť aj dosť konterproduktívne, skúsil by som ho vynechať úplne.

[ja.]

resim s dodavatelem, ze jablecny kramy se neumej prihlasit domenovym uctem k firemnimu webu, cokoli jinyho funguje

Ale vedia, SPNEGO s Kerberom aj NTML. Niektoré browsery však majú by default vypnuté SPNEGO (rovnako to je aj v Linuxe) a treba im whitelistnúť hostname alebo celú doménu, kde majú na SPNEGO reagovať.

[Reklama]

[kutildomaci]

Ste si istí, že nefungujú práve zložené UTF-8 znaky?

Ano, velmi jistý.

Dekódoval jsem název mizejících souborů nějakým UTF-8 HEX konvertorem a porovnal s funkčním názvem jiných souborů a téhož souboru po přejmenování, výsledek byl jednoznačný. Proto jsem zkusil použít vfs_fruit

Z mých dřívějších poznámek:
Když bylo ů = 0xc5 0xaf tak se soubor ve finderu zobrazil, když bylo ů = 0x75 0xcc 0x8a tak nikoli. Podobně s č = 0xc4 0x8d vs č =  0x63 0xcc 0x8c atd...

Tyto soubory, které uživatel MACku neviděl, byly vytvořené a pojmenované uživatelem Windows.

Jako nejsem si jistý, jestli vfs_fruit nepřináší víc problémů než užitku, ale problém s nezobrazenými soubory se tím nějak vyřešil. Doufám, pokud za to nemohou volby unix charset a display charset, které jsem měl tu a tam zakomentované a ztratil jsem přehled, kdy a za jakých okolností.

Fakt je, že jinde jsem vfs_fruit na Sambě použít nemusel (Na Gentoo se Sambou 4.19) a na jiných Debianech nebyl problém nejšpíš proto, že těch MACkařů tam není dost a ne všichni uživatelé píší diakritiku do názvů souborů...

[ja.]

Ste si istí, že nefungujú práve zložené UTF-8 znaky?

Ano, velmi jistý.

Dekódoval jsem název mizejících souborů nějakým UTF-8 HEX konvertorem a porovnal s funkčním názvem jiných souborů a téhož souboru po přejmenování, výsledek byl jednoznačný. Proto jsem zkusil použít vfs_fruit

Z mých dřívějších poznámek:
Když bylo ů = 0xc5 0xaf tak se soubor ve finderu zobrazil, když bylo ů = 0x75 0xcc 0x8a tak nikoli. Podobně s č = 0xc4 0x8d vs č =  0x63 0xcc 0x8c atd...

Tyto soubory, které uživatel MACku neviděl, byly vytvořené a pojmenované uživatelem Windows.

Jako nejsem si jistý, jestli vfs_fruit nepřináší víc problémů než užitku, ale problém s nezobrazenými soubory se tím nějak vyřešil. Doufám, pokud za to nemohou volby unix charset a display charset, které jsem měl tu a tam zakomentované a ztratil jsem přehled, kdy a za jakých okolností.

Fakt je, že jinde jsem vfs_fruit na Sambě použít nemusel (Na Gentoo se Sambou 4.19) a na jiných Debianech nebyl problém nejšpíš proto, že těch MACkařů tam není dost a ne všichni uživatelé píší diakritiku do názvů souborů...

Zaujímavé:

keď vytvorím súbor (tri pokusy: pomenovať cez finder, pomenovať v shelli na serveri cez ssh, pomenovať cez windows explorer), tak na serveri bol vyvorený názov denormalizovaný:

0000000  c4  8d  65  72  76  65  6e  c3  a1  2e  74  78  74  0a
          D  cr   e   r   v   e   n   C   !   .   t   x   t  nl
0000016  c4  8d  65  72  76  65  6e  c3  a9  2e  74  78  74  0a
          D  cr   e   r   v   e   n   C   )   .   t   x   t  nl
0000034  c4  8d  65  72  76  65  6e  c3  bd  2e  74  78  74  0a
          D  cr   e   r   v   e   n   C   =   .   t   x   t  nl

Ale macos klient ho videl normalizovaný:

0000000    63  cc  8c  65  72  76  65  6e  61  cc  81  2e  74  78  74  0a
           c   �  8c   e   r   v   e   n   a   �  81   .   t   x   t  nl
0000020    63  cc  8c  65  72  76  65  6e  65  cc  81  2e  74  78  74  0a
           c   �  8c   e   r   v   e   n   e   �  81   .   t   x   t  nl
0000040    63  cc  8c  65  72  76  65  6e  79  cc  81  2e  74  78  74  0a
           c   �  8c   e   r   v   e   n   y   �  81   .   t   x   t  nl

V rámci rýchlych pokusov sa mi nepodarilo vytvoriť normalizovaný názov na serveri, bude treba ďalšie pokusy.

[Michal Šmucr]

Taky si to ozkouším, až budu mít chvilku.. díky, že jste poslal konkrétní hex kódy těch znaků, co vás zlobí.

Ale bohužel se obávám, že tím co zkoušíte s vfs_fruit se tohle nevyřeší.

fruit:encoding řeší specificky jen chování CIFS klienta na MacOS když vytváří na share nový soubor, který obsahuje znaky, co jdou použít na HFS a APFS, ale nejdou použít na Windows (dvojtečka, lomítka, je větší, menší, pípa..). Ty pak přemapuje do privátního rozsahu Unicode. Tenhle rozsah pak Windows CIFS klienti ignorují, takže se souborem můžou normálně pracovat. Zároveň, když je tam MacOS klient má, tak si je remapuje zpátky.
Takhle se to chová bez jakéhokoliv spec. nastavení v MacOSu.
Když tam přidáte direktivu vfs_fruit:encoding = native, tak můžete změnit to, že to na serveru uloží soubor tak, že tam do jmén na standardní umístění místo neviditelných priv. kódů vrátí znaky, co jdou na UNIXech uložit (tzn. téměř vše mimo dopředného lomítka).
Pokud neuděláte nic, nebo explicitně nastavíte vfs_fruit:encoding = private, tak se to chová tak, jak jsem popisoval předtím.

vfs modul fruit neumí sám o sobě přemapovávat znaky, ale používá na to modul catia, kterému dynamicky předá potřebná přemapování, proto se musí při použití encoding = native stackovat dohromady s fruit.

Jinak ty ostatní volby fruit s tímhle nemají moc co do činění, při připojení z MacOS přidají do SMB protokolu některé Apple extenze, řeší různé způsoby ukládání metadat a resource forků, rekurzivní zamykání atd. Tzn. s největší pravděpodobností to ničemu nevadí, ale vašemu problému to nejspíš nepomůže.

Jediné, co by mohlo teoreticky něco řešit je zmíněný modul catia.
Ten umí i manuální remapování jednotlivých znaků (nejsem si jistý, ale sekvenci dvou znaků po sobě to podle mě nepobere, když se tam zadává mapa).
Ten by se pak nastavil na share, který by byl určený jen pro MacOS klienty a zkusil bych udělat mapu pro kódy samostatných znaků s akcenty (v češtině asi jen čárka, háček, kroužek a přehláska) a každý z nich nahradil nějakým jedinečným kódem pro nepoužívaný ufonský znak, u kterého si vyzkouším, že nedělá ve Finderu problém.
Ta mapa musí funguovat oběma směry, tzn. když MacOS klient soubor zapíše zpět, tak aby se to spolehlivě vrátilo do původního názvu, který se používá na share pro Windows klienty. Proto to například nejde jednoduše nahradit všechny akcenty třeba jednou univerzální pomlčkou (kdyby se ve jméně vyskytlo více různých akcentů, tak by to zpátky uložilo jiné jméno souboru).
Ale to je samozřejmě jen nápad 

[Michal Šmucr]

Tak ozkoušeno a potvrzuji popsané chování.
Jakmile je tam v názvu ta denormalizovaná varianta, tak se na MacOSu nezobrazí.
Není to věc Finderu, ale vestavěného CIFS klienta, protože to nevypisuje ani v terminálu (jako kdyby tam ten soubor nebyl).
Zkoumal jsem další nastavení CIFS klienta (man nsmb.conf), kde se dají dolaďovat různé věci, ale nic souvisejícího jsem neobjevil.

Napadlo mě v rychlosti vyzkoušet ze serveru NFS export, který se pak nechá z Finderu připojit přes cmd+k - connect a nfs://server:/share
Tam to ten soubor sice normálně zobrazuje i ve Finderu, ale při pokusu o otevření v Texteditu to řekne, že soubor nebyl nalezen.
V terminálu to otevřít třeba vimem jde, ale musí se odescapovat název např: Pokus\ 3bajty\ -\ u\314\212\ nebo\ 2bajty\ -\ \305\257.txt.
Takže sice to vypadalo nadějně, ale funkční to taky nebude.





Poslední varianta, co mě napadá, je vyzkoušet ještě starý dobrý AFP. Apple sice říká, že je deprecated a soustředí se jen na CIFS, ale i v posledním OSu zatím normálně funguje.
Pokud by to fungovalo a nezkomplikovalo by vám to život jinde (ověření, práva), tak se to přes Netatalk na serveru dá většinou bez potíží provozovat souběžně se Sambou.
V stable Debianu 12 není v balíčcích, ale je jak v testingu, tak v Sidu. Jestli budu mít chvíli čas si backportovat balíček, ještě to otestuju.

[František Ryšánek]

Pánové velice děkuji za toto vlákno. Nějaká jabka se nám tu začínají objevovat, samozřejmě odshora. Aspoň nebudu čučet, jestli dorazí tyhle legrace.

Já jsem si všiml dvojího kódování diakritiky (jeden háčkovaný znak vs. háčky čárky v samostatném znaku) proti jabku poprvé v IMAPu. Tuším šlo o složku "odeslaná pošta" (nebo jak se jmenovala) - Apple Mail si ji původně v IMAPu vytvořil v jedné konvenci, a následně po nějakém updatu ji očekával v "té druhé háčkové konvenci", a protože ji takovou nenašel, tak si tu složku vytvořil znovu. Načež viděl jenom tu novou a ne tu starou. Cyrus viděl obě, jiní imapoví klienti viděli obě, v linuxovém shellu byly vidět obě. Dva adresáře se "shodným" háčkovaným názvem :-) Popravdě v mém případě byl jistý minimální rozdíl i v zobrazeném znaku (Putty), ale musel jsem mít obě verze vedle sebe, abych je dokázal rozlišit.

To bylo řečí, že Unicode vyřeší diakritiku jednou provždy :-D

[jjrsk]

Ale vedia, SPNEGO s Kerberom aj NTML. Niektoré browsery však majú by default vypnuté SPNEGO (rovnako to je aj v Linuxe) a treba im whitelistnúť hostname alebo celú doménu, kde majú na SPNEGO reagovať.

Tohle me vzdycky bavi, kdyz nekdo vubec nema paru vocogo, ale zacne blabolit uplny nesmysle.

Tak ozkoušeno a potvrzuji popsané chování.
Jakmile je tam v názvu ta denormalizovaná varianta, tak se na MacOSu nezobrazí.
..

Tak muzes naprasaka takovy soubory proste prejmenovat tak aby se zobrazily. Napises si na to nejaky replace, pokud resis jen cestinu nebude to nijak dlouhy.

[jjrsk]

...IMAPu...

Tyhle rosady jsou bezny i ve svete opic utlouka a treba exchange, ty slozky v imapu se jmenujou podle toho, jaka verze office (vcetne jazykovy mutace) je zalozila. Totez plati pro kalendare atd atd. Takze pokud pak chces v roli admina dat lidem neco treba do toho kalendare, tak to je vazne k popukani.

Jinak mam nekde na disku takovej ukazkovej folder kde mam asi 50 souboru, a vizuelne bys rek, ze se vsechny jmenujou stejne. Proste a jako а

[ja.]

Tohle me vzdycky bavi, kdyz nekdo vubec nema paru vocogo, ale zacne blabolit uplny nesmysle.

Tak sa bav ďalej, keď riešiš nezmysly, ktoré všetkým ostatným cez 20 rokov bez problémov fungujú. Hlavne že najlepšie vieš, vocogo.

[jjrsk]

Jiste ty tupce a proto dodavatel predelava login celyho webu vid? Protoze to funguje ... lol. Ty retarde, tady vubec nejde o jebly ntlm, to se vubec nepouzije, proc by jako probuh melo? Ale ten appli kam se proste nedokaze prihlasit domenovym uctem, nejpis proto ze nedokaze do webovyho formulare vyplnit ani ty pismenka spravne.

[Petr Branik]

Jiste ty tupce a proto dodavatel predelava login celyho webu vid? Protoze to funguje ... lol. Ty retarde, tady vubec nejde o jebly ntlm, to se vubec nepouzije, proc by jako probuh melo? Ale ten appli kam se proste nedokaze prihlasit domenovym uctem, nejpis proto ze nedokaze do webovyho formulare vyplnit ani ty pismenka spravne.

jake pismenka do weboveho formulare? Prihlasovani domenovym uctem do webovych aplikaci na macos samozrejme funguje, ze to tvuj dodavatel a ty neumite neni problem macos.