Windows 10 a neúspěšné spojení na Sambu

[datlikMS]

Dobry den,

ak ma niekto na windows 10 urobeny "mount" na samba network share (ci uz adresar alebo disk), ma to ulozene (ci uz s prednastavenym uzivatelom/heslom), nasledne tento "mount" na network share zrusi a vytvori nanovo, moze este niekde zostat informacia o povodnom "mounte"? Nemam pristup na ten PC, ale vidim neuspesne connection tj neviem, ci to zostalo niekde vo windows alebo ten clovek nezvladol odstranenie network share (location).

Dakujem
m

[Reklama]

[Marek Staněk]

Jasně.
Control Panel, hledací box, Credentials Manager
Windows Credentials

[jjrsk]

Ty credentials ti IMO nebudou vyrabet pokusy o pripojeni toho share. Videl bych to na nejakou frikulinskou featuru treba widliho indexovace. Proste to ten disk jenou videlo a navzdy se ho to pokousi indexovat. Nebo tak neco.

Pripadne je treba si uvedomit, ze pokud za mount myslis pripojeni pod pismenko, tak to zdaleka neni jediny zpusob, a dokonce nektere aplikace si i tak z toho seberou sitovou cestu, a pouzivaji prave tu. Takze pokud tam neco takovyho ma, tak se to pri startu proste snazi najit nejaky drive otevreny soubor.

[Marek Staněk]

Jo, nějaká taková blbina to bude, jenže když dáváš NET USE /PERSISTENT:YES nebo dáš v dialogu připojení kredence s fajfkou Uložit trvale, tak si to právě uloží kredence do tohohle nastavení a pak se to snaží otevřít spojení právě s nimi. A i když pak připojení zrušíš nebo dáš NET USE /DELETE /Y, zůstanou tam uložený.
A pak stačí aby se změnilo heslo, a i když to připojení dávno nepoužíváš, tak při každým přihlášení se to snaží to spojení znova navázat, a ten účet se v závislosti na nastaveních dokáže zamknout během 5s, protože se to vyhodnotí jako útok.

[Standa Blábol]

V konzoli "net use"
A pro to, co nechces, "net use /DELETE"

Google a ChatGPT jsou tvoji pratele.

[Reklama]

[Rovano _]

V konzoli "net use"
A pro to, co nechces, "net use /DELETE"

Google a ChatGPT jsou tvoji pratele.

To je ale obejití problému a situaci dané "vadné" mašiny neřeší. což jsem pochopil, že autor dotazu požaduje.

[František Ryšánek]

Nevím zda je něco z následujících poznámek relevantní:

Mám historickou zkušenost, že když z namapovaného síťového disku spustím instalátor (něčeho), tak on se následně switchne na jiného uživatele - čímž nemusí mít přístup na ten namapovaný síťový disk. Ten "jiný uživatel" by mohl být "LOCAL SYSTEM" nebo tak něco. U starších generací Windows (XP?) na tom instalátory havarovaly = "nešlo spustit instalátor přímo ze sítě". Novější verze Windows (sedmy a výš) si v této situaci "nepochopitelně" řeknou o login na síťový disk (přestože už je jednou namapovaný).
Z podobného soudku: síťové disky přimapované konkrétním uživatelem fungují pouze v době, kdy je tento uživatel přihlášený (a pouze pro něj). Pokud se dotyčný odhlásí z desktopu, disk se patrně odmapuje (nebo není přístupný pro jiné usery). Toto je konkrétně problém v "naplánovaných úlohách". Pokud jako naplánovanou úlohu spouštím skript, musím v rámci tohoto skriptu disk přimapovat (NET USE) a po použití opět odmapovat (NET USE /DELETE). V těchto případech nepoužívám /PERSISTENT:YES.

Jo a jak kolega zmiňoval credentials manager, tak do něj jsem lezl tradičně v příkazovém řádku příkazem "cmdkey". Začal bych cmdkey /list . Pokud systém při pokusu o přimapování disku házel chybu, aniž by se zeptal na heslo, bývalo to tímhle. Cmdkey v tom případě umí jednotlivý záznam smazat.

[Marek Staněk]

Ale vždyť to je správně. Obecně nechceš, aby libovolný jiný uživatel měl na síťových discích stejná práva jako ty.
Pokud potřebuješ, aby všichni uživatelé měli nějaká konkrétní práva na síťovém sdílení, tak jim
a) vytvoř účty a nastav na sdíleních práva, nebo
b) vytvoř společného uživatele a tomu na sdíleních nastav práva, a toho pak použiješ v logonskriptu k tomu konkrétnímu sdílení.

[František Ryšánek]

Ale vždyť to je správně. Obecně nechceš, aby libovolný jiný uživatel měl na síťových discích stejná práva jako ty.

O tom vůběc žádná :-)

Spíš mě překvapilo, že něco instaluju na kompu, kde jsem přihlášenej jako lokální uživatel s právy administrátora, ale instalace selže na tom, že systémové instalační prostředí běží pod ještě jiným svým uživatelem :-) Nikoli třeba na bezpečnostním pravidle, že přímo ze síťových disků nemá kdokoli cokoli spouštět. Každopádně mám pocit, že tímto uhýbám od původního tématu.

Mimochodem mapování práv z Windowsů skrz Sambu na Linuxový server a jeho podkladový FS (resp. opačným směrem), to je při bližším pohledu taky docela chuť. A není to nutně něco proti Sambě jakožto softwarovému projektu - prostě jenom takový můj subjektivní heterogenní postesk.