... Weet je ook hoe je een username en password mee kan sturen?
Ik heb deze standaard namelijk niet ingevuld staan ivm private shares die standaard niet zichtbaar zijn met mn default user.
In XP en Vista idenficeert windows zich voor SMB/CIFS standaard met gebruikersnaam en password waarmee op Windows is ingelogd. Vandaar ook het veelvuldig advies om de NAS en Windows user/password combinaties synchroon te laten lopen.
Hoe dat in Win7 nou exact zit weet ik niet; ik kreeg soms direct verbinding onder de user credentials waarmee ik was ingelogd, en soms werd door Win7 om een user/password combinatie gevraagd.
Bij het mappen van een netwerkshare aan een stationsletter kan je expliciet de credentials aangeven, zowel wanneer je dat via "map drive" doet, als wanneer je dat middels het "net use ..." commando doet. Maar drive mapping kan alleen op share-niveau, en niet op de root van de shares.
Wil je je drives niet "mappen", dan is er in XP en Vista de Stored User Names and Passwords-tool, en in Win7 de Credential Manager, waamee je beheert met welke identiteit je naar netwerkresources verbindt.
Zie bijv.
http://www.techrepublic.com/blog/window-on-windows/manage-network-logon-credentials-in-microsoft-windows/2734.
Dit moet echter op netwerk-root niveau. Omdat alle NAS shares de netwerk-root delen (ofwel "\Jouw_NAS_IP, danwel "\Jouw_NAS_netwernaam") biedt dat geen oplossing.
XP (Vista en Win7: nooit geprobeerd) staat je zowieso niet toe om tegelijk onder verschillende identiteit met verschillende shares op dezelfde netwerlocatie te verbinden.
Dit ongeacht of je nu middels drive-mapping werkt of niet.
Mijns inziens een uitgesproken zwakheid van Windows. Een soort omgekeerde Meervoudige Persoonlijkheid Stoornis ...
Mogelijk is er toch nog een uitweg (maar die heb ik voor dit specifieke geval nog nooit geprobeerd).
Je kan met runas (command-prompt of *.cmd file: "runas.exe") opdrachten uitvoeren met een andere identiteit.
Meestal wordt dat gebruikt om wanneer je bent ingelogd als gewoon User of PowerUser taken als administrator te kunnen draaien, maar je kan ook een andere identiteit specificeren. Het moet dan een user betreffen die al bestaat op de locale machine, of je moet een domeinuser specificeren waarvoor een login server beschikbaar is. (Runas prompt
altijd om het password voor de de bewuste user.)
Daarmee zou je je identiteit op orde moeten hebben (direct of zoals voor die user voor de bewuste netwerklocatie gespecificeerd middels de Credential Manager), maar of Windows dan wel meerdere identiteiten naar dezelfde netwerklocatie accepteert betwijfel ik.
Mogelijk is ook daar weer een uitweg voor, door achter
runas.exe /user:AndereUserNaam "%windir%explorer.exe /n,/e,\Jouw_NAS_IP" de optie
/separate toe te voegen.
Zoals bij meer programma's kan er normaal gesproken slechts 1 explorer process tegelijk aktief zijn, alhoewel daarvan meerdere instances kunnen bestaan. "Hangt" explorer, dan kan je het explorer process met de Task Manager killen, maar daarmee verdwijnen alle instances van explorer (zelfs kortstondig de Desktop).
Gebruik je de toevoeging "/separate", dan krijg je echt een tweede process.
(Er wordt geadviseerd /separate alleen te gebruiken indien je "bulkt" van de RAM (tenminste 4Gbyte), omdat dit geheugen vreet).
Wellicht dat een apart, tweede explorer process wel uit de voeten kan met een tweede identiteit richting een netwerklocatie.
Maar, zoals je ziet, zit je (als het al lukt) echt aan de grenzen van Windows.
Met het aanroepen middels FTP is het simpel om tenminste de user direct te specificeren.
Maar ook dan zijn (standaard) geen twee verschillende identiteiten tegelijk mogelijk naar dezelfde netwerk-root.
Plerry