Ty si porad myslis, ze samba pepa je posix pepa a to neni pravda u Samba.

Neverim ze to bude formatovanim, s tim souvisi jenom fuse a ten ti umozni allow-others kdyz to premountujes spravne. V tvem pripade mozna bude stacit: force user = pepa v smb.conf

Jako nejlepsi reseni pro samba vidim formatovat XFS ci ext4 a pripojit dovnitr uz existujiciho sdileni.
Tim si overis ze problem je jenom u konkretnich disku.

JADE: v Nastavení - Odpojitelná úložiště - jsem zapnul [x] Povolit automatické připojování odpojitelných médií.
Před tím jsem přes right-click v sekci Zařízení dával Připojit.
s fstab jsem lehce experimentoval, ale vzhledem k tomu, že i drobná chyba vedla k tomu, že systém nenaběhl, tak mě to přestalo bavit. Z Windows jsem zvyklý, že můžu s hardwarem libovolně šachovat a systém to nějak pobere. Linux tak benevolentní není.
Snažím se o co nejjednodušší řešení. Aktuálně je to tak, že jsem nainstaloval na jeden fyzický disk sysém Kubuntu 19.04, aktualizace a cca 2-3 softy. Pak jsem připojil druhý disk, kde jsou výpočetní data, zapnul automatické připojování a opět přes kontext menu nastavil sdílení, jak jsem zvyklý ve Windows.
Protože nefungovalo sdílení toho disku, tak jsem zkusil udělat v home ten další adresář a tam to normálně jede, tzn. sdílení v systému (samba) je plně funkční.

MCKIDNEY: uživatel pepa má ke všemu full access a je owner. Všude. Ve Windows dávám samozřejmě přihlásit pomocí jiných pověření a jde to jen do toho sdílení v adresáři home/data1. Disk data2 to sice vidí, ale nepustí mě to tam, že prý nemám dostatečná oprávnění... i když v linuxu mají obě složky úplně stejné nastavení.

Zkusím tam dneska dát jiný disk, který bude naformátovaný třeba ext4 nebo exFAT a uvidíme, co to udělá...

Nicmene v tomhle pripade si myslim: bud user pepa nema pristup, nebo windows uzivatel neni pepa.

muzes zkusit napsat getenforce a zjistit zda je zapnuty SELinux
pomoci ls overit ze ma pepa prava na adresar s x
pomoci windows vynutit ze je to opravdu pepa kdo se prihlasi.

no ntfs muze byt problem protoze je to fuse a tedy systemova sluzba tam nebude videt.
Nicmene to same muze byt zpusobeno pomoci SELinux.

podle me muze bejt problem i v mountovani...jak mas ten disk namountovanej ? natvrdo pres fstab, nebo se ti pripojuje az po nabootovani, pres "pruzkumnik" a to mountovaci tlacitko ? jinak pres sambu sdilim z linuxu ntfs disk s datama do site bez problemu, ale teda jen slozku s filmama a mp3...

VYHULENY_UFO: Podívám se po tom exFAT.
Obecně mi jde o to, abych uměl v linuxu (ideálně Kubuntu) nasdílet celé disky a přistupovat k nim (hlavně) z Win7/10.
Na MS Win je to sranda... ale chci tuhle službu přenést na linux.

VYHULENY_UFO: aha... takže když bych ten disk naformátoval pod linuxem jako ext4, tak by problém být neměl?

VYHULENY_UFO: Nejsem si jistý, ale asi jsem to formátoval pod W7 (NTFS) a data tam nahrnul pod linuxem. Žádný fuse ani jiné speciality nepoužívám...
Zkusím to dát do stroje s W10, ale to už dneska nestihnu...

CHOROBA: owner je všude stejný, uživatel pepa

VYHULENY_UFO: disk se systémem je ext4
disk data2 má souborový systém "fuseblk" což vidím poprvé :-o

Zdravím všechny.
Mám triviální začátečnický problém a nemůžu najít řešení, dokonce ani gůglem :)

Jde o obyčejné nastavení sdílení mezi Ubuntu a Win7.

PC1 Linux
- HDD1 - system Kubuntu 19.04, v "home" složka "data1"
- HDD2 - data2

PC2 Win7
- HDD

Z PC1 -> PC2 není problém

Z PC2 (W7) -> vidím PC1 (data1, data2).
Na data1 lze z W7 přistupovat.
Na data2 NELZE z W7 přistupovat.
data1 i data2 mají v linuxu zcela shodné nastavení sdílení. Guest read only, user pepa full access.

data1 = složka vytvořená na HDD1 v home
data2 = druhý fyzický disk.

Problém je ten, že nedokážu zpřístupnit druhý disk v linuxu pro počítač s Win7. Vidět je, ale hlásí, že není přístup.
Na co jsem zapomněl? Co dělám špatně?
Děkuji za rady.

E2E4: metadata

MA747: hele a nejni to spis tim ze ti to nedava tiskarna ? postscript muze byt narocny na pamet tiskarny pokud je pdf debilne udelany potrebujes bud nejaky preprocesor nebo vic ramky v tiskarne.
Pokud si matne vzpominam, tak kdyz neni pamet tak tiskarna nejak komprimuje.
mozna tiskarne nesedi dpi nejakeho prvku tak konvertuje.

KOC256: ja mluvim o "záloha mění hash".

E2E4:
mluvim o tom scriptu co jsi posilal tu.

E2E4:
ne to NAS, tak asi nejak osekany...

KOC256: to ti fakt nerozumím.. jako že ty kousky už neodpovídají tomu celku, protože se ten celek změnil dalšími zálohami?

KOC256: ehm to první mělo být echo p/* na konci

a ad to druhý.. starej bash? nebo vůbec ne bash?

E2E4:
jo normalne :) ale kdyz v tom nelezis denne, tak to clovek musi "nastudovat" :)
kazdopadne diky

KOC256: nechápu, jak záloha mění hash?

normálně postupně přidávat na konec a odmazávat

for i in cast*
do
cat cast$i >> celek
rm cast$i
done

E2E4:

admin@NAS:/volume1/Shared/_WORK/x$ mkdir p; touch p/hz p/ch; echo *
p
admin@NAS:/volume1/Shared/_WORK/x$

admin@NAS:/volume1/Shared/_WORK$ diff -u <(ls -tr) <(ls *)
-sh: syntax error near unexpected token `('
admin@NAS:/volume1/Shared/_WORK$

Tak nakonec byl problem uplne jinde... ...mezi zidli a klavesnici - protoze ta zaloha meni hash...

Ale chtel bych se vratit k myslence, jestli nejde spojit ten cilovy soubor bez toho aniz by najednou existovaly vsechny kopie tech partu a pomalu vznikal i ten cilovy soubor.

Dokazu si predstavot nejaky cyklus, ktery spoji 1+2 a pak 1 a 2 smaze. Pak 12 + 3 a smaze 3, pak 123 + 4, atd atd.

Ale nejde to treba nejakym parametrem? i za cenu risku ztraty dat, kdyz se to behem toho posere - ze to mazani jiz spojeneho by delal na pozadi?

KOC256: pomalejší, ale při čtení z pomalého HDD se to zas tolik neprojeví.

pro tenhle účel je md5 ok, pravděpodobnost náhodné kolize je zanedbatelná ale pro kryptografický účely ne a proto je dobrý zapomenout že existuje :)

SAMGARR:
Pustil jsem to s vynucenym poradim...
cat part_aa part_ab ... | md5sum ... tak rano uvidim :)


E2E4:
Ten sha256sum je rychlejsi nebo kvuli kolizim?

Ten segmentovac, kdyztak zkusim pustit. Diky...

KOC256: head/tail -c a diff (ale teda nevim kolik pameti zabere binarni diff velkych souboru). ale ten md5sum je na to dostatecnej, teda mel bys spis pouzivat sha256sum.. :)

porovnat jednotlivy kusy on the fly pro pripad ze by skutecne byla jedna z casti poskozena muzes takhle:

segment=10; for i in zaloha.zip_part*; do head -c ${segment}G zaloha.zip| tail -c 10G | md5sum - ; md5sum $i; segment=$(($segment+10)); done

Takze ten cat ti to radi spravne? Pred casem jsem resil podobny problem a zjistil jsem (uz nevim proc), ze cat ty soubory radil ve spatnym poradi a proto nevychazel checksum.