Win2k3 server kérdések és problémák

Szóval van egy win2k3 SBS szerver 5CAL-os licenccel. Van rajta egy DOS-os program megosztva, valami könyvelőféleség. Két ember használja.

Panaszkodtak hogy nagyon lassú lett a program mióta szerveres dolog bevezetésre került. Tippem a win-es hálózat szar... az is, mint ez később bebizonyosodott.
Szóval kipróbálták úgy hogy távoli asztallal ráléptek a gépre, majd ugy turkáltak benne, tetszett nekik a sebesség. Igy türhető volt, de mivel ez SBS igy nincs vele Terminal Server, csak az adminisztrációs célra fennttartott desktopra tud csatlakozni 1 fő (talán 2, bár nekem még nem sikerült).

Kipróbáltuk a másolást egy jó sok kis fájlból álló könyvtárat (könyvelőprogi 5x) zuzztunk fel a szerverre majd vissza, és persze ugyanezt egy fele ilyen hw paraméterekkel rendelkező linux szerverre is megcsináltuk (vagyis megcsináltattam).
Workstation to Linux Server 2:27
Workstation to Windows Server 2:54
Linux Server to Workstation 2:50
Windows Server to Workstation 4:04
Amint látszik a wines szerver rosszabbul telejesít mint az 1000 éves linuxos társa.
Nem lehet a linuxra tenni a progit és ott megosztani, mert "not supported", és amúgy is elvileg futtani kell a progit amikor első indtása van a kliens gépeken.

Kérdések és kérések a dologgal kapcsolatban:
1. Lehet e Win2k3 SBS-hez Terminal Server-t venni, hogy és mennyiért (nem pontos ár kell hanem megközelitőleges)?
2. Hogy lehet javítani az idején a wines szervernek?
3. rdesktop lekezeli teljesen a RDP-s asztalt? Szóval majd használható lesz Terminal Serverrel? Pl. a kliensre kötött LPT-s nyomtatóval tudok majd nyomtatni, a szerveren futtatott DOS-os progiból?

Válaszokat előre is köszönöm

Hozzászólások

Az így megosztott program a klienseken fut. Így szerintem mennie kellene Linuxos megosztásból is, csak jól kell mappelni a hálózati meghajtókat.

--
The Net is indeed vast and infinite...
http://gablog.eu

Nem lehet a linuxra tenni a progit és ott megosztani, mert "not supported", és amúgy is elvileg futtani kell a progit amikor első indtása van a kliens gépeken.

Ha nem 2 napot szoptunk volna vele én sem hinném el.
Ha nem megy a szerveren akkor nem hajlandó a kliensen beregelni. Utánna már nem kell futnia a szerveren.
Kulcslemez és egyéb hülyeségek is vannak még, csak hogy izesebb legyen a dolog.

Érdekes probléma és jelenség. Mivel nem ismerem a programot, elégge morbidnak tűnik az, hogy a fileszerveren is futnia kell a programnak ahhoz, hogy a kliens aktivizálódjon. Egyáltalán képes a program hálózatos üzemmódra, vagy csak ráerőszakoltátok. (Pld. egy Novell szerveren futna? A fentiek alapján nem..., pedig a DOS időszakban nagyobb eséllyel szaladt bele az ember egy novell hálóba, mint egy linux/win hálózatba.)

Amikor a kliens beregelitek, akkor a szerveren futó program mit csinál? Csak fut, vagy valami spec menüben van (vagy éppen azzal lehet felvenni klienseket)?. Azért kérdem, mert én is "beüzemeltem" már pár DOS-s programot win és linux háló alatt is, és sehol semmi gond. Nekem pld. éppen a Samba alatt voltak/vannak olyan tapasztalatok, hogy bődületes mennyiségű filemegnyitás esetén vannak időszakos belassulások. Nekem "csak" annyi volt a feladat, hogy a kliens gépek lássák a szerver adott részét egy meghajtóként, majd mindegyik remekül elindítja a programot. A klienseken csak egy bat/link van a szerveren lévő programra. Persze a program eleve úgy van megírva, hogy képes hálózaton keresztül menni.

Esetedben a klienseken van valami a programból, vagy csak ott is egy link van a szerveren lévőre. Vagy valami kliens-szerver felépítés van megvalósítva DOS-ban?

A linuxhoz még annyit, hogy pld. én is küzdöttem vele, amíg tökéletesen belőttem a SAMBA-t, hogy minden klappoljon. Pld. a legnagyobb bibim az volt, hogyha a kliens lockolt egy rekordot az adatbázisban, akkor azt a többi kliens nem észlelte, és többen felülírhatták egy időben ugyanazt a rekordot (ezzel persze nem kis káoszt okozva)(Clipperes DBASE, semmi sql és társai :) ). Aztán a konfigban minden jogosultságot alapértelmezettre vettem, minden olyan spec. funkciót, amiben szerepet a DOS meg a lock szó bekapcsoltam :D és azóta csont nélkül megy. Ja az még lehet, hogy fontos, hogy a SAMBA megosztás share, nincsenek userek, azzal mindenkinek mindent szabad! Nemt tudom, hogy ti hogyan próbáltátok, esetleg próbáljátok meg így is, mert lehet, hogy valami jogosultsági ok miatt nem tud a kliens beregisztrálni.
És az is lehet, hogy totál rossz úton járok....

A +1 TS hozzáférést úgy tudod elérni, hogy az mstsc /console paranccsal indítod.

Lehet tudni milyen halo kari van a gepben?? Az olcso katos halo karik szoktak ilyen jellenseget okozni pl.

Ha a konyvelo progi tenyleg DOS-os en nem pedig Dos-osnak tuno windows-os progi akkor 1000%-ek, hogy lehet Linuxos serverre cserelni a cuccot.

( Kedvenceim a regi konyvelos progik... ( VFP, CIPPER mindet lehet Linux alol nyomni akkor meg nem voltak olyan securty megoldasok amit nem lehet kijatszani :D )

A Linuxra NEM váltást okát ide irom mindenkinek válazolva:

Leirom a varázsszót mégegyszer: "not supported on linux", válaszuk az volt hogy biztos meglehet oldani linuxon is, ők nem próbálták, ha nem akarunk szivni akkor win szerver.

Futnia kell a proginak a gépen amikor a kliens regisztrál rá. Ne kérdezd minek nem én irtam. Futnia kell és kész, másképpen nem megy. Ha már be van regelve a kliens akkor már nem kell futnia.

Eléggé olyan a program hogy csak rá van erőszakolva a hálózatos futás.

Hali,

1. Tudtommal SBS -hez nem lehet terminal servert venni, alapbol meg csak a 2 parhuzamos kapcsolatot engedelyezi max.

2. Ha SBS akkor gondolom tartomany van. Ebben az esetben a dns ellenorzese erosen ajanlott, ( event wiever-t is nezd /asszem igy hivjak windozon a syslogot/). Plusz rakj fel egy wins -t is. Valamint a support/tools mappaban van valami kis progi amivel meg tudod nezni hogy ki a local master browser stb... ezek is hasznosak lehetnek elso korben. Aztan dcdiag, stb...

3. Nekem teljesen jol mukodik, ts-el is hasznalhato. Az LPT -s kalandot nem probaltam, igy arrol nincs tapasztalatom.

ui: en hasonlo dolgot samba alatt tapasztaltam, aztan atraktam en is win2k3 std -re, mert nem akartunk tul sokat szivni vele.

J

Amikor a másolásos tesztet csináltátok, a többi "sokkal több" felhasználó mit csinált? Nem védeni akarom az MS-t, csak legyen tiszta víz a pohárban. Mert tény, hogy látványosak és meglepőek az időadatok, na de ha közben még pld. 6 másik kliens tette a dolgát a szerveren, akkor már más egy picit a helyzet. Ha win és linux alatt azonosak voltak a körülmények, akkor nem szóltam, visszaszívom, sorry stb.

Egyébként meg részvétem a könyvelő program miatt, mert a licenszek miatt is jobb lenne a linux - arról nincs infó, hogy mire használjátok még. (Asszem MS "hardwired" módon max. 10 egyidejű felhasználót (ftp/http/lan/stb) enged. Még akkor is ha 5 licensz van az SBS-hez, 10 kliens egyidejűleg simán megy vele, a 11. viszont már nem.)

Amivel én is szembesültem már: ha egy mezei felhasználó hozzászokott a saját gépén hasító programhoz, akkor mindenképpen panaszkodni fog a hálózatos (vagy hálózatosított) verzió sebessége miatt.

Esetleg egy ötlet: Mi lenne, ha kihagynátok a szervert? Próbából esetleg az egyik könyvelő gépet kinevezni "szervenek" (azon ugyebár win van), megosztani, hogy csak a másik gép lássa és kettejük között lenne egy másik hálózat, csak könyvelésre. Így az egyik felhasználó(a "szerver" tulaj) az tutira örülni fog, mert nála hasítani fog, meg hátha javul esetleg a sebesség valamit. (Egy XP prof is tökéletes 10 kliensig fileservernek, főleg ha az ember lelövi a fölös dolgokat. Be sem kell jelentkezetni, csak teszi a dolgát.)

OFF:
Mi is ezt hittük. Small Businnes Server, 5 licensz. 10 felhasználó remekül belép, 11. már nem. (Azt, hogy a licenszt túlléptük, most mellékes :) )
De ugyanezen szervecsomag, ftp és webszerver futott rajta tesztként, és esetenként a weblap nem elérhető, ftp timeout stb... szóval sejtésünk szerint, ha a külvilágból 10-nél többen léptek fel, akkor már gond volt. Ezen mi is csodálkoztunk, és lehet, hogy mi voltunk a balfékek nem mélyedtünk el benne nagyon... a szerverről az ember azt gondolná, hogy szerver sokak számára :)
Lehet, hogy az volt a gond, hogy apache és (már nem emlékszem milyen ftp, de nem MS termék) volt fent :). Aztán licensz++ utasítást tettünk egy ciklusba :) és egyből megszűntek ezek a gondok. (Persze azóta már tárgytalan)

Igen mások voltak a viszonyok.
A linuxoson kb. 6 ember volt bent, nyitogatott word doksikat, stb...
A windowsoson 1 max 2 ember.
Szerver azért kell mert eléggé poros a környezet, workstationokat rendszeresen homokozóban kell takarítani. Ez pedig elzárva van egy légkondis teremben, ahol nem járkálnak szaros gumicsizmával.
Másik oldal az adatok védelme, betörés esetén igy nehezebb elérni a gépet, min. + 3 ajtót jelent. Nem is az adatmentés miatt, hanem aki elviszi eléggé fontos céginfókat kapna meg, ugye....
Arról nem is beszélve hogy ezeke a "szerverek" 0-24ben mennek, pl. távolról is elérhető, stb...
Juliska nem fogja nekem bekapcsolva hagyni a gépét a 35℃ irodában.

"Panaszkodtak hogy nagyon lassú lett a program mióta szerveres dolog bevezetésre került."

Korábban hogyan használták ketten?

És esetleg nem érné meg lecserélni a könyvelő programot valami modernebbre?
Úgy veszem ki a szavaidból, hogy a tieteknekmá igencsak lejárt az életciklusa, s ha esetleg ezt a mostani problémát megoldod, lehet, hogy jövőre jön egy olyan, amit nem fogsz tudni megoldani...
Egyébként a cég, ahonnan vettétek, küld jogszabály-követő frissítéseket?
MErt ha igen, valószínűleg megvan még a forráskód, talán rendbe lehet rakatni egy DOS-os assembly/C/Clipper buherátorral a hálózatos részt is...

Nemrég választották ezt, a többi egy kicsit drágább volt. Eddig is voltak vele szivások, de mégis ezt válsztották. :D
A winnel is voltak eddig is szivások mégis ezt választották. :D
Lehetett volna olyan progi aminek csak egy ORACLE szerver kellet volna, ami ugye akár linux is lehet. Csak enyhén szolva volt egy kicsit drágább.
Ja amint irtam, ilyen szempontbol nem lehet velük beszélni, mert olyanok mint a szemellnzős lovak. Ha valami rossz akkor biztos mi basztunk el valamit és hasonló hozzáállások.
A jogszabályokat tartják, hisz másképp nem is lehetne eladni új sw-t, de a technológiát nem követik. Szerintem nem mai darab a .DBF fájlokkal felépített adatbázis.
Valószínüleg a táblák között van kapcsolat és sok nyitogatás kell sok táblában egy bizonyos adat lekéréséhez, ezért lehet lassú.

Ha dbf, akkor gyanítom Clipper. Annyira nem ismerem a többi DOS-os programozási nyelv ilyen jellegű rejtelmeit, de szerintem a Clipper az a nyelv, ahol a legegyszerűbb egy nem hálózatos program hálózatossá alakítása ha megvan a forrás. És most már komolyan érdekelne, hogy milyen regisztrálási megoldást kreáltak, aminél szükséges az, hogy a szerveren is fusson a program :). (esetleg megsúgod a program nevét, hátha fellelhető valami demo valahol?)
Komolyra fordítva: bocsi, hogy ennyit lovaglok a témán, de koromból kifolyólag ez a világ kicsit közelebb áll hozzám :), és a mai napig szórakozom ilyen rendszerekkel. A linux/win sebességre is azért kérdeztem rá, mert van két cég, ahol ugyanaz a DOS-s program megy hálózatosan (fileserver és 10+ kliensek). A program amikor "teljes gőzzel" fut, akkor felhasználók akár 100+ file-t is megnyitnak kliensenként. A kliensek win98, XP, sőt még egy DOS-os is akad. Az egyik cégnél win szerver van, a másiknál Debian Samba-val. Alapvetően mindkét helyen hasít a program, a Samba-nál fordulnak elő időnként pár másodperces lassulások, de nem vészes.
Szóval szerintem a programban van valami elmókolva, vagy pedig hálózatosítás helyett valami trükközés lett beledrótozva.

Én olyasmire gondolok, hogy pl. egy bérszámfejtéskor egy egy dolgozónál megnyitogat vagy 20-30 fájlt (vagy még sokkal többet) amivel a az adatokat kiolvassa, a kapcsolatokat felépíti a táblák között. Ha ezt megismétli kb. 200 dolgozónál, akkor már látszik is a sebességcsögkkenés.
A fenti teszt is mutatja hogy pl. a linuxos szerverről lemásolva a fájlokat 3/4-d idő alatt végeztünk.

A 3. ponthoz:
Mivel DOS-os programról van szó, ha meglesz/van a +2 TS, akkor még szerintem ezzel lehetnek gondok. Elméletem szerint ezt csak úgy lehet kivitelezni, hogy a szerverre fel kell venni hálózati nyomtatónak a kliens gépeken lévő nyomtatókat, majd a szerveren az LPT1: portot át kell irányítani rájuk. Merthogy a szerveren futtatják a programot, az ott kiadott nyomtatás az ottani LPT portra fog menni. Win98 alatt egy két kattintás, XP alatt már valami nyomtatók készletezése "szöveggel" megy ill. net use ltp1: stb. trükkel, hogy az SBS alatt melyik verzió van azt nem tudom. És itt egy újabb probléma, hogyha a két könyvelő a saját nyomtatójára akar nyomtatni, akkor passz. Az lpt portot két különböző nyomtatóra kellene átírányítani, ami szerintem nem megoldható. (FIXME) Illetve nem tudom, hogy a könyvelő programban van-e olyan lehetőség, hogy kliensenként be lehet állítani a nyomtatóportot (LPT1:, LPT2:) - bár az "előzményeket" olvasva erre kicsi az esély.
Ha egy hálózati közös nyomtatót használnak, akkor ilyen gond elvileg nem lesz. És persze a nyomtatás sebessége miatt is lehet, hogy pampogni fognak :), mert ugyebár elmegy a kliens gépről az utasítás a szerverre, hogy az ott futó program nyomtasson az lpt portra, majd a szerver az lpt portra küldött anyagot visszaküldi a kliens megosztott nyomtatójára.

Én is arról beszéltem (lehet, hogy nem az jött le), hogy a kliensen van a nyomtató. De ha a program maga a szerveren fut (pld. "távsegítség" ablakban), akkor a kliensen lévő nyomatót a szerverre fel kell csatolni(és telepíteni) mint hálózati nyomtatót, hogy a szerveren futó program tudjon rá nyomtatni. De gondolom ezt sikerült megtenned hajnalban. És ha a kérdéses program DOS-os, akkor annak meg kell egy elérhető LPT port, amit össze kell rendelned a hálózati nyomtatóval. (hacsak nem támogatja a program a hálózati nyomtatást... amire szintén kicsi az esély az előzményeket tekintve) És itt jön a bibi, ha esetleg mindkét könyvelő a saját nyomtatóját akarja használni....

Semmit nem tudtem megosztani felé mivel nem voltam vele egy hálózatban.
Csak az RDP port volt kiforgatva a routeren.
És a következő parancssal működött a dolog, hátha valakinek kell ilyen:

rdesktop -r lptport:LPT1=/dev/lp0 win2003asgep.cime.net:98811

Feltettem a szerverre a nyomtatómat és LPT1-es portot választottam ki neki, majd nyomtattam.

Elnézve a mért időket kétséges, hogy a linuxra váltás megoldja a gondot, ahhoz többszörös sebességkülönbség kellene.
Tapasztalatom szerint a hálózati meghajtóról futó régi programok kérdése nem kezelhető jól. Általában ezek olyan fileműveleteket tartalmaznak belsőleg, amik hálózaton keresztül hatékonyan nem hajthatók végre. Persze a hálózat sebességével tünetileg kezelhető a dolog. Nagyon gyanús a hálókártya. Meg kéne nézni, hogy mi az átéresztő-képessége. Nem kizárt a driver, beállítás vagy sebesség-beállítás hibája.
Az SBS gyári állapotban tartományvezérlő. Egyszerűen és jogtisztán ez nem változtatható, így gyanítom, hogy a tied is az.

mrceeka

Ez lehet, hogy nem a legjobb helyre szúrom be.

A hálózattal kapcsolatban: jártam már úgy, hogy nem tökéletes hálózat eseten a átviteli sebesség csökkentés gyorsulással járt. Egyszerű kábelteszter szerint vezezékek ok, nincs szakadás, nincs túl hosszú patch kábel sem, és mégis dögöc a rendszer. Visszaállítottuk kínunkba a sebességet 10 Mbps-re és egyből hasított. Ez win-es rendszer alatt volt. A kártyák autodetect módban voltak, és így megpróbáltak 100M-val menni, ami látszólag ment is (ping érték jó, távoli könyvtárak olvashatóak), és mégis a programok futása gyík lassú volt. 10 megán meg megtáltosodtak. Mivel szintén DOS-os programok voltak egy próbát esetleg megér...

(A problémát amúgy egy 3 méteres pacthkábel okozta. "színre rendezve" voltak bekrimpelve a vezetékek. Átkötöttük, és onnantól kezdve ment a 100 mega. Ez még lelkivilágomnak külön téma, hogy 100 megán miért nem mindegy, hogy a piros mellett piros-fehér v. kék van :) de ez itt off:)

----
ui: tényleg, a win-es hálózat fix ip-s, vagy milyen?

"problémát amúgy egy 3 méteres pacthkábel okozta. "színre rendezve" voltak bekrimpelve a vezetékek."
- Mekkkkorát szoptam ilyennel a hétvégén :)
kábelteszter jó sorrendet villogott. Ping hol volt, hogy nem volt.
Valaki az egész alhálót színre rendezve krimpelte be :)
Még jó hogy volt nálam elég csati...

áááááááááááááááááááááááááááááááááááááááááááááááááááááááááááááá
a "B" is büdös mert nem open szerinti ... 10 éve csak keresztkábelnél használtuk ... minden hálót "A"-val húztunk, ja akkor még nem támadott ilyen hévvel a #C $ CO. :)
_____________________
www.pingvinpasztor.hu

Meg egy hozza szolas ereig boncolgatnam a dolgot.
1. Megneznem milyen halo kari van a gepben ha valami olcso realtek csipes csoda az tud ilyen fajta lassulast okozni. kikukaznam es cserelnem a franba
2. A Xp max 10 kapcsolatot tud kezelni. SBS fogalmam sincs meg kell nezni a lic-et
3. Az Rdesktop kepes arra hogy ha a nyomtato az adot gepre nem automatikusan van telepitve akkor azt atvigye a halozaton vagyis a serveren megjelik a clien-s gep nyomtatoja abban az esetben ha ez nem ip alapu nyomtato.
4. Az ip alapu nyomtato is lehet jo megoldas.. Pl pint server es az felcsatolni mindegyik gepre mint LPTx
5.Meg kell tudni pontosan milyen programozasi nyelvu a konyvelo progi, lehet hogy egy file size vagy egy cipper stb stb sorok az autoexex es config-ban megoldast jelent.
6. Olyan nincs hogy nem lehet megoldani.

/ Nekem egy nyomdaban mondtak azt hogy a nyomdai ipari gep rendszer gazdai azt mondtak ez a gepet nem lehet halozatban kezelni.... Kedves rgazda urak ha jol tudom 3 napot szenvedtek a sajat termekukel es nem tudtak beuzemelni halozatosra.... en mindossze 1,5 orat kaptam erre a muveletre es lasss csodat mukodott is ;) bar hozza teszem a ceg mukodes kozben eleg sok rgazat emeszett fel es X evig fent allt a problema Tanulsag: Vagy nem ertettek hozza vagy nekik nem volt kihivas a dolog megoldasa/

Vigyázz a TS-el, meg a DOS-os programokkal. Nálunk egy-két turbo pascal futtatható, többnél már szaggat (dual core-os a "szerver"). A DOS-os programok szépen felzabálják a procit. Pl 4 userre quad-core-os gépet tegyél. Ha esetleg te is szeretnél még dolgozni rajta, akkor lehet gondolkozni 8 core-osban.

Nem lenne egyszerűbb lecserélni azt a programot? Megfenyegetni a céget, hogy ha nincs natív windows-os program (esetleg sql backend-el) akkor ugrik a szerződés? Felénk is sokan használnak még ilyen szemeteket (technikai megvalósításuk mindenképpen az), de a rendesebb cégek elkezdték kihozni a Win-es programokat.

Cserén gondolkoztak, rövidtávú ár/érték arány miatt ezt vették...
Egyre jobb ez a microsot.... eddig a cégnek kb. a 10x-ébe kerül a semmi, a linuxos dolgokhoz mérve.

Huzza a f...ára a TCO-t aki kitalálta. Hülyiteni lehet vele a corvinusos (senki ne vegye magára) tömeget...
Majd 1-2 óra mulva bemegyek előben is a céghez és leülök velük beszélgetni hogy mennyi pénzük van. Ha milliókrol lesz szó akkor maradunk a winnél. Ha milliórol lesz szó akkor lesz linux.
Egyértelmüsíteni fogom a pnzügyi részeket, hátrányokat, előnyöket.

Következő a gondom.
Adott egy szkript win2k3 alatt ami adott mappákat file-okba tömörít egy hálózaton lévő gép megosztásába.
A szkriptet lefuttatva kézzel gyönyörűen lefut. Beteszem ütemezett feladatok közé adott user alatt akinek admin joga van és a hálózati megosztáshoz is hozzáférhet. Be be vagyok jelentkezve akkor szépen lefut ütemezetten is. Azonban ha kijelentkezek, akkor már nem.

Mi lehet a gond?

nem lehet, hogy a távoli gép könytárát betűvel szeretted volna elérni a scriptből? (pl. M:\akármi)

mert azt ugye sejted, hogy amikor nincs belépve senki, akkor nincs felmappelve az M: drive... szóval \\SERVER\SHARE lehet ilyenkor a megoldás.

ja, és ha egy másik user be van lépve a gépen, és ő is eléri éppen ugyanezt a távoli szervert (valamit mappel a \\SERVER-ről), akkor nem fogsz tudni az övétől eltérő usernévvel a scriptedből elérni ugyanarról a szerverrel könyvtárat. ez azért van, mert egy windowos gép egyidőben csak egy file share kapcsolatot tud fenntartani egy másik windowsos szerverrel, és azon az egy kapcsolaton csak egy user lehet éppen bejelentkezve - egy másik usernévvel ilyenkor nem lehet semmit csinálni.

a usernév okés, mert annak a nevében fut a program, tehát azt tudhatja, de a jelszó nem biztos, hogy eltárolásra kerül.
egyébként a samba logjából kideríthető, hogy mivel próbálkozik (ill. tud-e jelszót produkálni).

vagy azt is meg lehet próbálni, hogy a script elejen net use, user+pw megadásával, hátha az jó lesz.

mondjuk esetleg azért kéri be a jelszót, hogy meggyőződjön róla, hogy jogosult vagy az adott felhasználó nevében scriptet berakni.

bejelentkezett felhasználó mellett azért tud lefutni a script, mert az interaktív felületen bejelentkezett felhasználónak mindig tárolja a jelszavát a windows addig, amíg be van jelentkezve, és ha ilyenkor próbálsz távolra bejelentkezni, először mindig az aktuális felhasználóval és az eltárolt jelszavával próbál belépni.

szerintem a windows share technológia nem teszi lehetővé azt, amit szeretnél. én lehet, hogy inkább local diszkre csinálnám a fájlt, aztán scp-vel átmásolnám a szerverre (kulcsos authentikációval nem kell jelszó, és korlátozható a szerveren, hogy mit engedsz meg azzal a kulccsal).