Hej!
Jag har ett märkligt problem.
Jag har ett par datorer som skall ha åtkomst till en accessdatabas som ligger på en server (Windows 2003 SP1). Klienterna finns i en domän, servern ligger utanför domänen i en workgroup. Klienterna mappar upp servern via ett uppmappningsscript:
net use X: \\10.153.122.23\accessdb myPassWord /Persistent:NO /user:MyUser
Problemet är att jag inte har skrivrättigheter på servern via den uppmappade sökvägen. Jag har t o m tilldelat MyUser full kontroll på servern utan resultat. Jag har också lagt upp MyUser i administratorsgruppen och tagit bort MyUser från Users. Jag har gett Everyone full kontroll och Users full kontroll. Jag har startat om servern varje gång mellan dessa ändringar för att vara helt säker på att ändringarna slår igenom.
Ändå får jag hela tiden:
Unable to create the file 'New Text Document.txt'
Access is denied.
om jag tex försöker skapa en textfil i Utforskaren.
vad som är MYCKET MÄRKLIGT är om jag loggar in via Terminal Services på servern med MyUser (som nu är administrator) så fungerar det att skriva till mappen. Inga problem. Men alltså inte om jag går via uppmappningen (kom ihåg: samma konto, samma lösenord). Nu behöver jag hjälp!
Hej igen!
Det verkar vara skillnad på att köra ett script med NET USE och att mappa manuellt i Utforskaren. Av någon anledning fungerar det i a f när jag mappar manuellt. Men detta vill jag undvika, så huvudfrågan kvarstår!
RikardMedlem sedan dec. 199917 055 inlägg Jag sätter inga pengar på detta, men det kan ändå vara värt att fundera över.
En uppmappning via ett skript behöver inte nödvändigtvis använda samma GUID som när du är inloggad. Det här problemet sprang jag på när jag satte upp backupfunktionen på webForum-servrarna. Skriptet funkade inte, men manuellt gick det hur bra som helst. Det hela slutade, i mitt fall, med att jag fick lägga med net use-kommandot i den bat-fil som körs precis innan backupen går igång.
I mitt fall spelar det ingen roll när uppmappningsskriptet körs, drar jag igång det manuellt genom att dubbelklicka på
.cmd-filen när jag är inloggad får jag fortfarande samma problem...
RikardMedlem sedan dec. 199917 055 inlägg Nu testar vi ett wild shot...
net use X: \\10.153.122.23\accessdb myPassWord /Persistent:NO /user:10.153.122.23\MyUser
Tror jag testade den utan resultat. Jag skall kolla när jag besöker servern imorgon...
Nej, det fungerar inte. Nu märker jag att det är samma fel om man mappar upp manuellt med admin-kontot. Inga skrivrättigheter helt enkelt, trots att man har bockat i allt. Måste varit trött i huvet. Känns som om det är någon policy som ligger i vägen...
Hallå igen!
Nu gick jag in i Control Panel>administrative tools>Computer management>Shared Folders>Shared, högerklickade>Properties och ändrade rättigheterna på fliken Share Permissions. På något sätt skiljer sig Share permissions från Security Permissions. PÅ security-fliken hade jag korrekt rättigheter, men på Share Permissionsfliken fanns ej skrivrättigheter.
INte för att jag fattar hur det fungerar, men detta verkade fungera.
RikardMedlem sedan dec. 199917 055 inlägg Share permission är rättigheten för att komma åt filen från nätet. Security permission är rättigheterna på filnivå.
Om du ansluter till en dator från nätet så kommer share permission att vara det första du stöter på. Om du enligt share permission har rättighet att läsa eller skriva filer så är du en bit på väg. Security permission kan dock fortfarande sätta stopp genom att förneka dig läs-/skrivrättigheter till filen ändå.
Säkerheten fungerar enligt additionsprincipen. Den mest restriktiva inställningen är den som gäller. Säger share eller security att du bara får läsa, då är det enbart läsrättighet du har.
Jag hoppas att denna något klumpigt ihopslängda förklaring sprider lite ljus i rättighetsmörkret.
