Dotaz: Samba - práva k přesunutému souboru

[vandrovnik]

Dobrý den,

narazil jsem na následující zádrhel a nevím, jak to rozmotat. Zákazník má Samba (4.7.1) share, v ní dvě složky - 1. faktury ke schválení a 2. faktury autorizované. Do první složky mohou zapisovat skoro všichni uživatelé, do té druhé jen pár vyvolených přesouvá soubory z té první složky.

Potíž je, že když uživatel přesune soubor z 1. do 2. složky, soubor si s sebou nese i svá práva:

* getfacl PokusAH.txt
# file: PokusAH.txt
# owner: ...
# group: DokumentyFakturyKeSchvaleni
user::rw-
group::rwx
group:DokumentyFakturyKeSchvaleni:rwx
mask::rwx
other::---

Přestože složka, do které byl soubor přesunut, má nastaveno:

* getfacl 2.\ Faktury\ autorizovane
# file: 2. Faktury autorizovane
# owner: ...
# group: DokumentyFakturyAutorizovane
# flags: -s-
user::rwx
group::rwx
group:DokumentyFakturyAutorizovane:rwx
mask::rwx
other::---
default:user::rwx
default:group::rwx
default:group:DokumentyFakturyAutorizovane:rwx
default:mask::rwx
default:other::---

Pokud by uživatel v té 2. složce soubor vytvořil (nebo ho tam zkopíroval), tak bude mít práva v pořádku:

* getfacl PokusAH.txt
# file: PokusAH.txt
# owner: ...
# group: DokumentyFakturyAutorizovane
user::rw-
group::rw-
group:DokumentyFakturyAutorizovane:rwx
group:DokumentyPlnyPristup:rwx
mask::rwx
other::---

Tzn. můj problém spočívá v tom, že při přesunutí souboru se neaplikují defaultní práva nastavená té cílové složce, ale soubor si přístupová práva přinese s sebou z původního umístění.

Nevíte prosím někdo o způsobu, jak tohle chování změnit? Cílem je, aby se práva přesunutého souboru nastavila podle cílové složky.

Díky,

Karel

---

---

Odpovědi

[NN]

At si v Samba konfiguraci na cilove slozce nastavi korektne prava pres force-* direktivy a tom share. Co ja vim Samba nastaveni souboroveho systemu ignoruje..

[vandrovnik]

Samba to nastavení souborového systému dodržuje - pokud bych použil force-xx, tak nevím, jak bych vůbec mohl řídit práva k jednotlivým složkám v rámci share...

[LarryL]

Příkaz mv nemění práva nebo vlastníka přesouvaného souboru. Není to bug, ale vlastnost - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=402332#22. Má to svoji logiku, protože ty nevytváříš nový soubor, ale pouze přesunuješ/přejmenováváš originál.

[pavele]

Já mám v smb.conf pouze:

create mask = 0664

directory mask = 0775

Na adresáři mám nastavený bit SGID (drwxrwsr-x).

A vše funguje i při přesouvání souboru.

Změní se jak uživatel na toho, který soubor přesouvá a skupina na skupinu uživatele, který soubor přesouvá (vlastně na SGID).

Testováno uživatelem ve Windows 7 na Samba 4.7.1, bez ACL.

Pokud potřebuji upravit přístupová práva, změním je na serveru - přidám nebo uberu skupinu uživateli, změním práva na adresář atd.

Pokud přistupuješ z linuxu, asi by měl být v smb.conf parametr:

unix extensions = no

[LarryL]

Dal jsem si do smb.conf:

create mask = 0664

directory mask = 0775

unix extensions = no

a zkusil jsem to v Thunaru na linuxu (Vyjmout > Vložit) a je to tak jak jsem popisoval - vlastník, skupina i práva zůstaly zachovány z původního souboru. Zkoušel jsem to i z Win10 a výsledek stejný. To platí jen pro přesunutí souboru, u kopírování se vlastník i práva samozřejmně změnily.

Možná, že u tvé Samby nepoužívá filesystem mv, ale cp a pak starý soubor smaže. Že by to bylo ovlivněné SMB klientem? Nebo máš nějaký nestandardní mv.

Moje samba: Version 4.8.5

[pavele]

U mne je struktura složek:

                  --->  složka-1 -> podsložka sdilena-uživatel-1(SGID) -> testovací-soubor
                  |              -> podsložka sdilena-uživatel-2(SGID)
sdilena-složka ---               -> podsložka sdilena-uživatel-3(SGID)
                  |
                  ----> složka-2 -> podsložka skupina-1(SGID) -> přesunutý testovací-soubor
                                 -> podsložka skupina-2(SGID)
                                 -> podsložka skupina-3(SGID)

Test přesunu jsem prováděl z Win7.

[LarryL]

Taky jsem měl takovou strukturu složek. Takže otázka za milion dolarů: Čím to je, že se ti dědí práva?

Když na serveru kde máš Sambu použiješ mv, tak se ti ty práva také zdědí?

Když dáš příkaz alias nemáš tam vypsáno mv?

[vandrovnik]

Vlastně by asi stačilo, když by každá ta složka byla samostatně namountovaná? Hádám, že pak by se vždy použilo kopírování+mazání místo přesunu (práva by byla OK, ale nejspíš by se zároveň změnilo info o tom, kdo soubor vytvořil - už by to nebyl ten původní uživatel, byl by tam ten, kdo provedl "přesun"). Akorát mě nenapadá, jak to udělat, aniž by člověk musel každé složce předem rezervovat pevně danou velikost.

[LarryL]

Už se v tom začínám ztrácet co vlastně chceš. Ano u kopírování (ve výchozím stavu) se změní i vlastník (myslel jsem, že to chceš).

práva by byla OK, ale nejspíš by se zároveň změnilo info o tom, kdo soubor vytvořil

Není to protimluv? Práva by přece nebyly OK, když by byl zachován i původní vlastník, který by měl stále právo zápisu.

[vandrovnik]

Jo, tohle jsem napsal špatně, omlouvám se. Prioritou je, aby se nastavila práva podle té složky, do které je soubor přesunut. Zakázat vlastníkovi přístup by se sice dalo, ale jsou to zbytečné kejkle. Když už nebude vidět, kdo soubor vytvořil původně, nevadí to skoro vůbec.

[little-drunk-jesus]

No myslím, že nevnímáš koncept linuxových práv. Práva jsou primarně přiřazena uživateli. Ostatně se i tak jmenují user, group, others. Uživatel pod svými právy vytvoří soubor, ten má vlastnicví zachyceno v inode, ne v adresáři. položka v adresáři je jen odkaz na inode, ve kterém je info o souboru. Zkus si to a vytvoř si ve dvou adresářích hard link na jeden soubor. když změniš v jednom adresáři vlastnictví (nebo mod) tak se ti změní i v druhém. Při přesunu souboru se jen změní odkaz v adresářích na inode ale na nic dalšího se nesáhne.

[vandrovnik]

Já věřím tomu, že pro stávající fungování jsou nějaké důvody, jenže bohužel požadavek uživatelů je, aby to fungovalo jinak - mně osobně jejich přání připadá logičtější než to stávající fungování, ale chápu, že oba přístupy mají svoji logiku. Mimochodem, pokud se dělá přesun mezi filesystémy, tak mv dokonce vyvine nějaké úsilí navíc, aby tam dostal ta původní práva - kdyby tak byl nějaký globální příznak, kterým by se mu dalo říct, aby se na to vykašlal :)

Docela by mě zajímalo, jestli tady někdo má Sambu v ostrém provozu. Podle mě pak taky musí narazit na to, že šéf přesune nějaký dokument od sebe do jiné složky, kam mají mít přístup i zaměstnanci - a jak teda potom řeší práva? Nevěřím, že by ručně cosi upravoval.

[lertimir]

Triviální řešení je cronem pouštět chown -R vlastnik_slozky:skupina * v příslušném adresáři. pokud tam nejsou statisíce souborů tak je to rychlé.

[vandrovnik]

Souborů je tam něco přes 300.000 a práva jsou poněkud košatější (některé skupiny uživatelů mají složku jen pro čtení, někdo čtení i zápis apod.). Ale cron mě asi stejně nemine, akorát v něm pomocí getfacl a setfacl vždy nějak převzít default hodnoty ze složky, ve které soubor je, a aplikovat na soubory a složky v té složce.

[peekaa]

Prosím, pokud bude možno, o sdílení řešení.

[vandrovnik]

No, prozatím mám tohle:

# Argumenty: jedna nebo vice slozek
# Skript zjisti prava zadane slozky pomoci getfacl.
# Tato prava rekurzivne aplikuje na vsechny vnorene soubory a slozky.

while [ "$#" != "0" ]; do

 echo
 echo $1
 sed "s/./-/g" <<< $1

 PravaVsechna=`getfacl -p "$1"`
 PravaDefaultni=`getfacl -p -d "$1"`

 # aplikujeme defaultni prava rekurzivne na soubory v zadane slozce a vsech vnorenych
 find "$1" -mindepth 1 -type f -print0 | while read -d $'\0' Polozka; do
  #echo Soubor: "$Polozka"
  setfacl --set-file=- "$Polozka" <<< "$PravaDefaultni"
 done

 # aplikujeme prava i defaultni prava rekurzivne na slozky v zadane slozce a vsech vnorenych
 find "$1" -mindepth 1 -type d -print0 | while read -d $'\0' Polozka; do
  #echo Slozka: "$Polozka"
  setfacl --set-file=- "$Polozka" <<< "$PravaVsechna"
 done

 # prejdeme na dalsi argument
 shift

done

Za náměty na vylepšení předem děkuju

Ještě to během zítřka otestuju a asi to dopadne tak, že tohle se občas spustí v cronu na všechny soubory.

Jinak existuje incron, který by měl umět hlídat změny ve složce a pokud ke změně dojde, něco spustit. Tzn. pro složky, kde by bylo dobré, aby se práva opravila co nejdřív, bych nastavil hlídání pomoci incron, který by zavolal ten skript na opravu jen pro zadanou složku. Incron bohužel neumí hlídat rekurzivně a asi není dobrý nápad mu předhodit k hlídání desítky tisíc složek (8192 je výchozí hodnota pro max. počet hlídaných složek v /proc/sys/fs/inotify/max_user_watches).

Na Sambě jsem nastavil force group na nějakou skupinu, ve které nikdo není.

[LarryL]

Ten script nezmění vlastníka souborů. To je záměr?

[vandrovnik]

Zatím nemám rozmyšleno, jakého vlastníka by bylo ideální tam dát. Nabízí se: nechat původního (tak to zatím je), nastavit podle složky (to by asi bylo nejsprávnější, jen jsem v noci už nenašel elegantní způsob, jak si vypsat vlastníka složky), nastavit podle uživatele, který provádí ten přesun (to neumím a možná to ani nejde, ale odpovídalo by to tomu, co se stane, když uživatel nejprve přesune soubor k sobě třeba na plochu a pak ho přesune zpátky na síť) nebo nastavit nějakého úplně jiného.

Původně jsem si myslel, že to udělám tak, že přístupová práva pro uživatele nastavím na --- a práva se budou řídit jen podle skupin, které vyjmenuju v ACL, ale když jsem to zkoušel, tak ta uživatelská práva --- měla přednost před rw právy skupiny.

[LarryL]

Nabízí se: nechat původního

Pokud to všechno děláš hlavně proto, aby s těmi schválenými fakturami už neoprávnění zaměstnanci nemohli manipulovat (v případě že by se taková faktura dostala třeba do adresáře kde ostatní mají právo čtení), tak pokud nezměníš vlastníka, tak je tvoje snaha k ničemu protože původní vlastník (nějaký pepa z účtárny) bude moci soubor editovat nebo měnit práva.

nastavit podle uživatele, který provádí ten přesun (to neumím a možná to ani nejde...

Ve chvíli přesunu by to šlo jednoduše: chown whoami path/to/file ale zpětně v cronu už to nezjistíš.

Pokud chceš kopírování práv opravdu jen u příkazu mv a všechno ostatní je OK, tak jestli místo inotify to nepřilepit přímo na to mv, nějak takto:

alias mv='moje_mv.sh'

cat moje_mv.sh

#!/bin/bash

mv "$@"

result="$?"

if [ "$result" -ne 0 ]; then

	CilovySoubor=<zjistit z $@>

	if <cesta CílovehoSouboru == cesta sdíleného adresáře Samby>; then
		chown whoami <CílovySoubor>
		getfacl -p <RodičovskýAdresář CilovehoSouboru>
		setfacl --set-file=- <CílovySoubor>
	fi
fi

[LarryL]

Ty poslední 2 řádky měly být takto:

PravaVsechna=`getfacl -p <RodičovskýAdresář CilovehoSouboru>`
setfacl --set-file=- <CilovySoubor> <<< "$PravaVsechna"

Takže snad je pochopitelné co tim chtěl básník říct

[LarryL]

Místo if [ "$result" -ne 0 ]; then má být if [ "$result" -eq 0 ]; then. Důkaz, že jsem unavený, good night.

[L!80r]

A doufat, že zaměstnanci nezačnou klikat oprávnění ručně a nedej bože si na to někdo zvykne.

[lertimir]

No myslím, že by sis měl primárně udělat přesně jasno, co vlastně chceš. A to v rámci toho, co je k dispozici. Pokud se budeme takto dozvídat po částech fňukání, že práva nefungují, jak zrovna teď by sis představoval s mnoha dalšími omezeními, jsou rady k ničemu. To že tam máš nějaká další složitá práva nikde nebylo řečeno. To že práva jsou primárně navázána k souboru má hluboký význam, že primární právo a rozhodnutí o právech má vlastník a není mu při posunu souboru přes FS nijak upíráno a automaticky modifikováno. Dokonce ani když soubor přesune někdo jiný (třeba root) se na vlastnicvía přístupových právech nic nemění. Nějaké rady jsi už dostal, modifikovat pirtomému managerovi, který neví, co dělá mv na "cp+del", udělat strukturu v různých sharech, (a windowsy už od doby XP umí připojit oddíl disk (a amyslím i share) do adresáře a nemusí mu dávat písmeno), dá se něco ošetřovat cronem, dá se udělat i to, že soubor bude s právy vždy zápisu pro všechny, jenom soukromé adresáře managera budou chráněny, že se z nich nedá číst nikomu a tím pádem se nedá na ten soubor dostat,

[peekaa]

Ježíš to jsou bláboly. Radši řekněte "nevím" nebo nic, když nevíte. Všichni ví o co jde, a už to bylo několikrát řečeno. Není třeba bránit Sambu a Linux, ten máme všichni stále rádi, nebojte

[k3dAR]

naopak, nastinil moznost ktera byla sice jiz recena, ale odmitnuta kvuli "hromade pismenkum", pokud lze ve Win pripojit share do adresare (nevim, vim ze lze pripojid fyzickej oddil do ntfs adresare od 2k nebo xp), tak by to mohlo byt reseni...

[lertimir]

Management přístupových práv je v zásadě datový model s definovanými operacemi. A stejně jako u mnoha jiných datových modelů, pokud na začátku je blbý návrh, mnohdy co nejjednodušší přístup, s tím, že se to později nějak doflikuje tak se lehce zjistí, že nedoflikuje. Tím že autor přiznal, že návrh je komplexnější než "vedoucí" a "podřízení" tak problém je jinde. Když by mě nějaký student přišel s podobným návrhem managementu, tak ho prostě ze zkoušky vyhodím.

[peekaa]

Pane profesore, prosím tedy vysvětlete mi, co je špatného na modelu: mám složku a požaduji, aby všichni (kdo má práva zápisu do složky) za každých okolností mohli v této složce editovat cokoliv, co se tam objeví *jakýmkoliv* způsobem od kohokoliv. At to tam kdokoliv nakopíruje nebo přesune nebo uloží nebo stáhne. Mě to přijde velmi legitmní.

[vandrovnik]

Dívejte - nevíte-li, jak poradit k danému problému, bude asi lepší si podobné komentáře ušetřit. Na dvou složkách, které jsem zmiňoval na začátku, je myslím dostatečně jasné, v čem problém spočívá. To, že firma má xx zaměstnanců, yy složek a různé skupiny uživatelů mají do některých složek právo rw, do některých r a do některých nic, protože tak to prostě v dané firmě potřebují a vyplývá to z pracovního zařazení jednotlivých zaměstnanců, je pro účely tohoto dotazu zcela podružné.

[LarryL]

Podle mě pak taky musí narazit na to, že šéf přesune nějaký dokument od sebe do jiné složky, kam mají mít přístup i zaměstnanci - a jak teda potom řeší práva? Nevěřím, že by ručně cosi upravoval.

V tomto případě by tvoje řešení s děděním práv mělo:

výhodu: je to rychlé, nic se musí ručně upravovat,

nevýhodu: jakýkoliv zaměstnanec s právy k dané složce by ten "šéfův" soubor mohl upravit.

Kdybys to takto tomu šéfovi vysvětlil, tak by z té výhodu už tak nadšený nebyl. Rychlé a jednoduché řešení nebývá vždy to správné.

[L!80r]

Ale to je snad správně, že jí zaměstnanec může upravit když to tam šéf přesunul

[peekaa]

Přesně.

[LarryL]

No pokud je to nějaká směrnice nebo info o navýšení/snížení platu, tak to správně není

[L!80r]

Takový soubor ale nemá co dělat ve složce, de mají zaměstnanci rwx.

[LarryL]

Pokud vycházíš z úvahy, že práva určuje nadřazený adresář, tak tam opravdu nemá co dělat. Tak to ale není. Práva k souboru, určuje samotný soubor. PS: Psal jsem o právech v samotném filesystému, protože Samba+Linux je trochu kočkopes.

[pavele]

Já věřím tomu, že pro stávající fungování jsou nějaké důvody, jenže bohužel požadavek uživatelů je, aby to fungovalo jinak - mně osobně jejich přání připadá logičtější než to stávající fungování, ale chápu, že oba přístupy mají svoji logiku. Mimochodem, pokud se dělá přesun mezi filesystémy, tak mv dokonce vyvine nějaké úsilí navíc, aby tam dostal ta původní práva - kdyby tak byl nějaký globální příznak, kterým by se mu dalo říct, aby se na to vykašlal :)

Docela by mě zajímalo, jestli tady někdo má Sambu v ostrém provozu. Podle mě pak taky musí narazit na to, že šéf přesune nějaký dokument od sebe do jiné složky, kam mají mít přístup i zaměstnanci - a jak teda potom řeší práva? Nevěřím, že by ručně cosi upravoval.

Já nevim. V mém případě prostě šéf přesune soubor na svou sdílenou složku a ostatní uživatelé do tohoto souboru mohou zapisovat. Proč ti to nefunguje a mě ano, nevim.

[LarryL]

Proč ti to nefunguje a mě ano, nevim.

Myslel jsem, že už to víš. Jak jsi o pár řádků níže napsal, tak složka1 a složka2 jsou na jiném (virtuálním) disku a to je důvod proč se ti soubor kopíruje (nepřesunuje) a žádné "úsilí navíc" se u tebe neprovádí. U mě "úsilí navíc" také žádné neprobíhá, nevím co tím bylo myšleno.

[LarryL]

Vlastně by asi stačilo, když by každá ta složka byla samostatně namountovaná?

Adresář můžeš namountovat příkazem mount --bind, ale pokud budou adresáře na stejném filesystému, tak ti to moc nepomůže - mv se bude chovat stejně. Můžeš použít "loopback device" nebo lvm, ale nemyslím, že to je jednodušší než cron/script. Navíc kdyby si chtěli vytvořit 16. adresář, tak bys musel přiběhnout a mountovat ho.

[pavele]

Příkaz alias mi vypíše mv -i.

Ale je fakt, že mám složku1 a složku2 samostatně namountovanou.

složka1 a složka2 je na jiném (virtuálním) disku (diskovém oddílu), tak to snad bude ten důvod...

[vandrovnik]

Ano, mv se chová úplně stejně. Doufal jsem, že Samba má nějaký parametr, který jsem přehlédl, který by uměl tohle chování změnit (klidně i za cenu toho, že by se interně místo přesunu dělalo kopírování). Té logice rozumím, ale bohužel uživatelé očekávají logiku jinou - nastavit právo pro složku a jakmile někdo jakkoli do té složky vloží soubor, měli by ho vidět ti, kdo mají právo k té složce, ne k původnímu souboru. Vím, že to takhle umí Novell, jak to mají nativně Windows, nevím.

Vytvářet pro každou takovou složku samostatný share by se jim asi nelíbilo, jsou zvyklí na to, že mají všechny dokumenty mapované ve Windows na písmenko, a mít najednou třeba 15 písmenek by byl pro ně hrozný chaos.

[LarryL]

Já vím jen o "force *" nastaveních v sambě, ale myslím, že se všechny vztahují jen na nové soubory.

Předpokládám, že uživatelé ze skupiny DokumentyFakturyAutorizovane jsou zároveň ve skupině DokumentyFakturyKeSchvaleni, takže by Autorizovaní členové měli vidět přesunuté faktury ve 2. složce. Jelikož uživatelé KeSchválení nemají přístup do 2. složky, tak je již nemohou změnit, takže tam problém nevidím. Takže jediné co bys potřeboval je cron, který 1x za den změní vlastníky a/nebo práva ve 2. složce.

Šel by udělat i alias mv, ale to se mi nezdá být správné řešení.

[vandrovnik]

Asi mě opravdu nemine ten cron, ale stejně je mi divné, že by všem vyhovovalo to standardní chování mv a nepotřebovali to mít tak jako ti "naši" uživatelé. Doufal jsem, že jsem jen něco přehlédl...

[Peter Golis]

Keby to štandardné chovanie nevyhovovalo všetkým, tak by sa nestalo štandardným chovaním.

Mimochodom, namiesto časového cronu by som odporučil niečo na báze inotify, alebo dnotify. Nespomeniem si ktorá implementácia sa preferuje v tejto päťročnici.

[vandrovnik]

Tak třeba na tom Novellu to je (pro mě odjakživa) jinak a taky si tam na to nikdo nestěžuje. Na Windows to vlastně asi taky je jinak, protože jim to "dřív" fungovalo dle očekávání (než jim win server umřel). inotify / dnotify zkusím nastudovat, díky za tip.

[Peter Golis]

Novell, to je dobrá archeológia. Ako sa vám tam darí stále bežať na IPX protokole?

[vandrovnik]

Píšu "Novell", ale aktuálně to je "Open Enterprise Server" (funguje vlastně jako "něco navíc" nad Suse Linux Enterprise Server), IPX dávno není potřeba používat a systém funguje k naší plné spokojenosti

[Peter Golis]

MARSNWE, alternatíva Novellu ktorou neskôr nahradil Novell ten svoj produkt? To je naozaj dobrá archeológia.

[vandrovnik]

O MARSNWE jsem nikdy neslyšel, tak nevím. OES 2018 je aktuální produkt, takže moc nechápu, co pořád máte s archeologií. https://www.novell.com/documentation/open-enterprise-server-2018/oes_readme/data/readme.html

[Peter Golis]

A majú v tom pribalené aj niečo novšie ako v tom linku odkazovaný NetWare 6.5 SP8 z jesene 2009 ktorý je založený na tom Marse ktorý nahradil pôvodný produkt?

PS: Keď vyhovuje, tak nevidím dôvod nahradzovať aj archeologický exponát. A ak k tomu nielen predajú, ale aj poskytnú podporu, tak prečo nie.

[vandrovnik]

Tak on je především NetWare 6.5 něco úplně jiného než OES. NetWare byl samostatný operační systém, sám o sobě nekompatibilní s čímkoli jiným (tudíž potřeboval svoje ovladače pro hw apod.). OES běží na linuxu (Suse)...

[Peter Golis]

Áno. Spomínam si ako vo firme Novell adaptovali ten mars na Linuxe.

[LarryL]

Jsi přesvědčený, že u Windowsů se při přesunu (na stejném svazku) převezmou práva z nadřazeného adresáře? Tady https://support.microsoft.com/en-us/help/310316/how-permissions-are-handled-when-you-copy-and-move-files-and-folders se o NTFS jasně píše:

By default, an object inherits permissions from its parent object, either at the time of creation or when it is copied or moved to its parent folder. The only exception to this rule occurs when you move an object to a different folder on the same volume. In this case, the original permissions are retained.

Takže jestli jsem ještě nezapomněl anglicky, tak by se to na Win mělo chovat stejně jako na linuxu, tzn. při přesunu jsou práva ponechána.

[vandrovnik]

No přesvědčený o tom nejsem, protože windows servery nikde neprovozuju, ale zákazník tvrdil, že předtím se jim to tak chovalo. Klidně je možné, že samotné NTFS se chová jinak, než když to je složka sdílená z Win serveru stanicím, nebo že se to chová jinak od nějaké verze Win serveru... To zmiňované MoveSecurityAttributes myslím od Windows 7 už nefunguje (zkoušel jsem a nepomohlo), tzn. možná tou dobou to chování změnili.

[vandrovnik]

Tak dnotify je prý obsolete.

"Inotify does not support recursively watching directories, meaning that a separate inotify watch must be created for every subdirectory."

Obávám se, že vyhraje cron, protože stejný problém bude v celé adresářové struktuře, tzn. různých adresářů tam budou tisíce :/ Nemluvě o tom, že na programování pro linux se moc necítím.

[peekaa]

Vadí to i dalším lidem, i mě a u nás ve firmě, také bych toto chování uvítal. Je pitomé se přizpůsobovat tomu,"co umí mv", místo toto, "co lidi oprávněně očekávají".

[LarryL]

Spousta lidí si pod "přesunutím" představí "znovuvytvoření" a když se jim ten soubor objevil na "novém" místě, tak to chápou jako "nový" soubor. Podle mě je lepší když jsou příkazy elementární, nadstavba v podobě dědění práv se dá vždy dodělat (alias by asi byl na jeden řádek).

V jiných firmách třeba vyhovuje současné chování mv. Vem si, že máš v účtárně více zaměstnanců tvořících faktury a podle vlastnictví souboru poznáš kdo ji vytvořil nebo na kterém počítači byla vytvořena.

[peekaa]

Za mě tedy nesouhlas. Lidi nepotřebují až tak vědět, kdo soubor vytvořil, ale mít jistotu: když je soubor v této složce, tak ho mohu změnit, at se tam dostal jakkoliv. A když je soubor v této složce, tak mi ho ostatní změnit ani smazat nemohou, at se tam dostal jakkoliv. Dost dobře nedokáži pochopit, jak po tolika letech, tato jednoduchá úvaha není plně v sambě implementována. Práva složky nade vše.

[LarryL]

tato jednoduchá úvaha není plně v sambě implementována.

Nejde o Sambu, ale u fungování filesystému, který se u příkazu mv chová podle pravidla: Trezor nemůže být odemčen pouhým přesunutím. Lidé si prostě neuvědomují, že při přesunu zůstává soubor v originálním stavu a to se týká nejen vlastníka a práv, ale také datumu vytvoření souboru, který bývá pro lidi také důležitý. Takže kdybys dal do Samby funkci, která by místo mv prováděla cp nebo prováděla nějako manipulaci s právy, tak by si zase lidé stěžovali, že Samba nerespektuje pravidla filesystému.

[vandrovnik]

Naši uživatelé to spíš vnímají tak, že dokument (soubor) byl někým přendán ze zamčeného trezoru (složky) do odemčeného trezoru (složky).

[peekaa]

Nesouhlas. Je to prostě feature, kterou by rádo více lidí, a která z mě neznámého důvodu není nějakou volbou implementována /asi by stačilo: místo mv použij cp a del/. Pravidla jsou taková, jaká si navolím, takže kdybych si v sambě navolil pravidlo: Práva složky jsou prioritní, tak by se to stalo pravidlem a naopak nerespektování tohohle pravidla by byla chyba.

[LarryL]

Tak pokud to myslíš jako volitelnou funkci navíc v Sambě, tak proč ne, ale rozhodně by to neměla být zadrátovaná funkce, která by se nedala vypnout. Když nad tím přemýšlím, tak by to pro Sambu znamenalo, že by musela umět měnit vlastnictví souborů, skupiny, práva na nejrůznějších filesystémech - takže se mi to nezdá tak triviální funkce.

[peekaa]

Opět - nesouhlas. Při prostém kopírování souborů systém "Práva složky primární" to funguje dobře, takže by stačilo cp + del. Samozřejmě ne jako symlink na mv, jak tady někdo šíleně navrhoval, ale pouze v rámci samby. Ale to je jedno - at tak nebo tak, i kdyby to bylo nepoměrně složitější, nechápu, proč to tam volitelně není již několik let.

[LarryL]

Proč ti to u Samby tak moc vadí, ale ve filesystému ti to nevadí?

Asi máš pravdu, že cp+del místo mv by nemuselo být tak složité. Vlastně by tato funkce mohla být pouze na straně Samba clienta. Jak jsme psali výše, tak to vypadá, že v Exploreru na Win to dříve bylo pomocí hodnoty "MoveSecurityAttributes". Když je to teda tak snadné a všichni to chtějí, tak proč to teda v žádném Samba clientu není a v tom Win to zrušili?

U nějaké alternativy Samby jsi takovou funkcionalitu, která by umožňovala přepínání "mv" vs. "cp+del" viděl?

[vandrovnik]

Nám to ve filesystému nevadí, protože přímo na něm uživatelé nic nedělají - tam když tak dělá něco admin a ten se s tím smíří a práva po přesunu opraví. Tzn. pro nás by stačilo, kdyby to nějak uměla obejít ta Samba. Ale pokud by to šlo nastavit přímo filesystému, bylo by to super

MoveSecurityAttributes možná odstranili právě proto, že teď se při přesunu ta práva nastaví podle cílové složky, ale nemám nikde žádný win server, na kterém bych si to mohl ověřit.

[LarryL]

Co vím tak na Windowsech jdou u souborů nastavit práva:

a) napevno (explicitní)

b) relativně (zděděno od)

U varianty a) se to při přesouvání souborů ve Win10 chová stejně jako na linuxu a jsem si na 99,99% jistý, že na Win Serveru to bude stejné.

U varianty b) se při přesouvání souborů práva pochopitelně změní, teda ony se nezmění, ale převezmou si práva odjinud a ty zřejmě chceš vědět jestli jdou i na linuxových filesystémech nastavit práva k jednotlivým souborům jako "relativní", je to tak?

[vandrovnik]

Ano, varianta b) je to, co by uživatelé potřebovali a já to bohužel neumím nastavit :/

[LarryL]

Nevím jak moc je dnes spolehlivý NTFS pod linuxem, ale pokud by ti někdo poradil, že přechodem z ext4 na ntfs získáš co chceš, tak bys do toho šel?

[JMP]

tím určitě nic nezíská, ale naopak ztratí - na ntfs pod linuxem jsou práva emulována globálně pro celý volume (nastavuje se to parametrama při mountování) a samotná práva na ntfs (ace/acl) to tuším obchází...

navíc je tu _velká_ degradace výkonu při práci s ntfs pod linuxem oproti nějakému nativnímu fs

[vandrovnik]

No, asi bych byl poněkud skeptický, pořád to vnímám tak, že podpora ntfs sice funguje, ale oproti nativním fs nebude ani zdaleka tak dobře odzkoušená...

[LarryL]

Já myslím, že žádná "relativní" práva u unixových systémů (tudíž ani u MacOs) nejsou. Do ntfs bych také nešel i kdyby tam ty "relativní" práva fungovaly.

[GeorgeWH]

Myslim, ze problem je uz v tom samotnom navrhu: 1x share, 2x zlozka. Podobne sme to riesili aj my (akura tych zloziek bolo niekolko a este aj podlozky a v roznych sharoch), ale nakoniec sa to zrusilo a pouzili sa samostatne shary.

[vandrovnik]

No ono to je spíš 1 x share, 15 x složka, tady se ale problém projevil rychle, u ostatních složek si zatím problému nevšimli, ale je to samozřejmě totéž. Bohužel opravdu chtějí pro jednotlivé složky řídit práva samostatně.

[debian+]

Pouzi rsync a nastav, ze zdroj nech maze a cielu nech nastavi urcite prava.

Alebo si napisat na to vlastny skript, program, kt. to bude za teba robit. Pripadne nejaky alias.