13
eingeschränkten Nutzer wollen Cookies in %windir%/Cookies ablegen
Internet Explorer der eingeschränkten Nutzer will Cookies in %windir%/Cookies ablegen
XP SP1 in Samba 3 Domäne
Hallo,
Ich habe ein Problem an einer Workstation mit XP Pro SP1, in Domäne an Samba (3.0.20b-SerNet-SuSE).
Logge ich mich als lokaler Admin an, legt der IE die Cookies in %userprofile%/Cookies ab.
Bei den Domänen Benutzern mit eingeschränkten Rechten, tritt "plötzlich" folgendes Problem auf:
-der Internet Explorer legt keine Cookies mehr an.
-bzw. wird versucht die Cookies in %windir%/Cookies abzulegen.
Natürlich klappt es wenn ich den Benutzern Schreibrechte in %windir%/Cookies gebe.
Allerdings sollten sie doch in %userprofile%/Cookies abgelegt werden.
Der Cache liegt %userprofile%\Lokale Einstellungen\Temporary Internet Files
[HKEY_USERS\SID....\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders]
"AppData"="c:\\Profile\\USERXY\\Anwendungsdaten"
"Cookies"="c:\\Profile\\USERXY\\Cookies"
...
"Local Settings"="c:\\Profile\\USERXY\\Lokale Einstellungen"
"Local AppData"="c:\\Profile\\USERXY\\Lokale Einstellungen\\Anwendungsdaten"
"Cache"="c:\\Profile\\USERXY\\Lokale Einstellungen\\Temporary Internet Files"
...
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Cache\Special Paths\Cookies]
"Directory"=hex(2):25,00,55,00,53,00,45,00,52,00,50,00,52,00,4f,00,46,00,49,00,\
4c,00,45,00,25,00,5c,00,43,00,6f,00,6f,00,6b,00,69,00,65,00,73,00,00,00
"CachePrefix"="Cookie:"
"CacheLimit"=hex:00,04,00,00
--
dabei sollte "Directory"=hex(2):25,00,55,00,53,00,45,00,52,00,50,00,52,00,4f,00,46,00,49,00,\
4c,00,45,00,25,00,5c,00,43,00,6f,00,6f,00,6b,00,69,00,65,00,73,00,00,00
= %USERPROFILE%\Cookies sein.
---
Die Index.dat im %userprofile%/Cookies kann ich löschen wenn ich als Benutzer angemeldet bin, scheint sie also überhaupt nicht zu benutzen.
Jmd schon mal so ein Problem gehabt und gelöst?
Samba läuft nicht mit LDAP.
Vielen Dank für Antworten!
XP SP1 in Samba 3 Domäne
Hallo,
Ich habe ein Problem an einer Workstation mit XP Pro SP1, in Domäne an Samba (3.0.20b-SerNet-SuSE).
Logge ich mich als lokaler Admin an, legt der IE die Cookies in %userprofile%/Cookies ab.
Bei den Domänen Benutzern mit eingeschränkten Rechten, tritt "plötzlich" folgendes Problem auf:
-der Internet Explorer legt keine Cookies mehr an.
-bzw. wird versucht die Cookies in %windir%/Cookies abzulegen.
Natürlich klappt es wenn ich den Benutzern Schreibrechte in %windir%/Cookies gebe.
Allerdings sollten sie doch in %userprofile%/Cookies abgelegt werden.
Der Cache liegt %userprofile%\Lokale Einstellungen\Temporary Internet Files
[HKEY_USERS\SID....\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders]
"AppData"="c:\\Profile\\USERXY\\Anwendungsdaten"
"Cookies"="c:\\Profile\\USERXY\\Cookies"
...
"Local Settings"="c:\\Profile\\USERXY\\Lokale Einstellungen"
"Local AppData"="c:\\Profile\\USERXY\\Lokale Einstellungen\\Anwendungsdaten"
"Cache"="c:\\Profile\\USERXY\\Lokale Einstellungen\\Temporary Internet Files"
...
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Cache\Special Paths\Cookies]
"Directory"=hex(2):25,00,55,00,53,00,45,00,52,00,50,00,52,00,4f,00,46,00,49,00,\
4c,00,45,00,25,00,5c,00,43,00,6f,00,6f,00,6b,00,69,00,65,00,73,00,00,00
"CachePrefix"="Cookie:"
"CacheLimit"=hex:00,04,00,00
--
dabei sollte "Directory"=hex(2):25,00,55,00,53,00,45,00,52,00,50,00,52,00,4f,00,46,00,49,00,\
4c,00,45,00,25,00,5c,00,43,00,6f,00,6f,00,6b,00,69,00,65,00,73,00,00,00
= %USERPROFILE%\Cookies sein.
---
Die Index.dat im %userprofile%/Cookies kann ich löschen wenn ich als Benutzer angemeldet bin, scheint sie also überhaupt nicht zu benutzen.
Jmd schon mal so ein Problem gehabt und gelöst?
Samba läuft nicht mit LDAP.
Vielen Dank für Antworten!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 18730
Url: https://administrator.de/contentid/18730
Ausgedruckt am: 19.12.2024 um 09:12 Uhr
13 Kommentare
Neuester Kommentar
Moin daniel_t,
soweit ich es im Kopf habe, müsstest Du bei
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Cache\Paths].... und dann Path1...Pathx
nachsehen.
Bei SpecialPaths sollte sogar "%SystemRoot%\Cookies" drinstehen (als REG_MULTI_SZ natürlich). Aber die SpecialPaths sind hier glaube ich nicht gemeint beim IE.
HTH Biber
soweit ich es im Kopf habe, müsstest Du bei
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Cache\Paths].... und dann Path1...Pathx
nachsehen.
Bei SpecialPaths sollte sogar "%SystemRoot%\Cookies" drinstehen (als REG_MULTI_SZ natürlich). Aber die SpecialPaths sind hier glaube ich nicht gemeint beim IE.
HTH Biber
Guten Morgen,
Danke für die schnelle Antwort!
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Cache\Special Paths\Cookies]
"Directory"=hex(2):25,00,55,00,53,00,45,00,52,00,50,00,52,00,4f,00,46,00,49,00,\
4c,00,45,00,25,00,5c,00,43,00,6f,00,6f,00,6b,00,69,00,65,00,73,00,00,00
"CachePrefix"="Cookie:"
"CacheLimit"=hex:00,04,00,00
also Directory = %USERPROFILE%\Cookies
---
Hm...
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Cache\Paths
sind alle 4 auf:
c:\Profile\LocalService\Lokale Einstellungen\Temporary Internet Files\Content.IE5\Cache1
Was gehört dort eigentlich rein?
%userprofile% ...
Danke für die schnelle Antwort!
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Cache\Special Paths\Cookies]
"Directory"=hex(2):25,00,55,00,53,00,45,00,52,00,50,00,52,00,4f,00,46,00,49,00,\
4c,00,45,00,25,00,5c,00,43,00,6f,00,6f,00,6b,00,69,00,65,00,73,00,00,00
"CachePrefix"="Cookie:"
"CacheLimit"=hex:00,04,00,00
also Directory = %USERPROFILE%\Cookies
---
Hm...
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Cache\Paths
sind alle 4 auf:
c:\Profile\LocalService\Lokale Einstellungen\Temporary Internet Files\Content.IE5\Cache1
Was gehört dort eigentlich rein?
%userprofile% ...
Hallo Daniel,
nur mal so ne Frage: Du sagtest du kannst die 'index.dat' net löschen, wenn du als Benutzer mit eingeschränkten Rechten angemeldet bist. Ja kannst du desauch wenn du mit vollen Rechten angemeldet bist? Wenn ja, sag' mir bitt mal wie du das gemacht hast. Des geht normalerweise nur über ein umständlichen Weg. Da musste ja voll rumgetrickst haben, das des mit rechts->löschen geht. Das ist eine systemgeschützte Datei, die man gar nicht verändern, geschweige den löschen kann (ausser über den umständlichen Weg)!!! Das hat Microsoft absichtlich so gemacht, da diese Datei toll fürs spionieren ist, da quasi dein komplettes Surfverhalten dort gespeichert wird).
Thx im Voraus
Bitte ein Bit
nur mal so ne Frage: Du sagtest du kannst die 'index.dat' net löschen, wenn du als Benutzer mit eingeschränkten Rechten angemeldet bist. Ja kannst du desauch wenn du mit vollen Rechten angemeldet bist? Wenn ja, sag' mir bitt mal wie du das gemacht hast. Des geht normalerweise nur über ein umständlichen Weg. Da musste ja voll rumgetrickst haben, das des mit rechts->löschen geht. Das ist eine systemgeschützte Datei, die man gar nicht verändern, geschweige den löschen kann (ausser über den umständlichen Weg)!!! Das hat Microsoft absichtlich so gemacht, da diese Datei toll fürs spionieren ist, da quasi dein komplettes Surfverhalten dort gespeichert wird).
Thx im Voraus
Bitte ein Bit
Hallo Daniel,
nur mal so ne Frage: Du sagtest du kannst
die 'index.dat' net löschen, wenn du
als Benutzer mit eingeschränkten
Rechten angemeldet bist.
nur mal so ne Frage: Du sagtest du kannst
die 'index.dat' net löschen, wenn du
als Benutzer mit eingeschränkten
Rechten angemeldet bist.
Nee umgekehrt ich kann sie löschen.
Die Index.dat im %userprofile%/Cookies kann ich löschen wenn ich als Benutzer angemeldet bin, scheint sie also überhaupt nicht zu benutzen.
Da keine Cookies angelegt wurden, wollte ich sehen ob der IE überhaupt die Datei in diesem Ordner nutzt (bzw. sperrt) - also gelöscht und es geht.
Ja kannst du
desauch wenn du mit vollen Rechten
angemeldet bist? Wenn ja, sag' mir bitt mal
wie du das gemacht hast. Des geht
normalerweise nur über ein
umständlichen Weg.
desauch wenn du mit vollen Rechten
angemeldet bist? Wenn ja, sag' mir bitt mal
wie du das gemacht hast. Des geht
normalerweise nur über ein
umständlichen Weg.
Nein normalerweise nicht, die wird aber auch benutzt, ist geschützt ....
und die Cookies an die "richtige" Stelle abgelegt, wenn ich mich als lokaler Admin anmelde.
Melde ich mich als normaler Benutzer an - besteht das Problem mit den Cookies...
Melde ich mich als Domänen Admin an - werden die Cookies auch unter
%windir%/cookies abgelegt, der Domänen Admin hat dort aber Schreibrechte und es gibt keine Probleme... das nützt mir aber nichts.
Der Benutzer muss auf eine bestimmte Seite - geht leider nur mit IE...
sonst wird der IE auch nicht genutzt eben nur für die eine Seite.
Komischerweise tritt das ganze jetzt auf 2 von 10 Rechnern auf,
meldet sich der gleiche Benutzer an einem anderen Rechner an ist alles OK.
Die Cookies werden ordnungsgemäss abgelegt.
An diesen 2 Rechnern ist was die Cookies angeht bei allen Benutzern der "Wurm" drin.
Sonst sind es 10 "identische" Rechner.
Ich weiss nicht wo man das noch festlegen kann...
Was habt ihr hier stehen:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Cache\Special Paths\Cookies]
und hier:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Cache\Paths
Hi Daniel,
sorry, ich hatte mich vertippt:
Das 'net' stimmt nicht, keine Ahnung, wieso ich des hineingeschrieben hatte. Ich war in Gedanken wohl schon weiter
Zu Deinem Problem:
Ich habs mir jetzt mal genauer angeschaut.
Mach's mal nicht so kompliziert und schau' Dir mal die einfachen Wege an. Öffne den I-Explorer und geh' unter Extras->Internetoptionen.
Dort kann man den Pfad zu dem Cookie-Ordner ändern. Auch wenn er richtig anzeigt wird, änder den Pfad zu deinem gewünschten Ziel. Windows macht des öfteren unerklärlichen Sch***. Wie sagte so schön der Prof aus I Robot: ... die vielen irrationalen Fehler der Computer ließen die Frage aufkommen, ob Maschinen einen eigenen Willen haben ... (oder so ähnlich)
Ich hoff' es hilft Dir
Simon
sorry, ich hatte mich vertippt:
Hallo Daniel,
nur mal so ne Frage: Du sagtest du kannst
die 'index.dat' net löschen, wenn du
als Benutzer mit eingeschränkten
Rechten angemeldet bist.
nur mal so ne Frage: Du sagtest du kannst
die 'index.dat' net löschen, wenn du
als Benutzer mit eingeschränkten
Rechten angemeldet bist.
Das 'net' stimmt nicht, keine Ahnung, wieso ich des hineingeschrieben hatte. Ich war in Gedanken wohl schon weiter
Zu Deinem Problem:
Ich habs mir jetzt mal genauer angeschaut.
Mach's mal nicht so kompliziert und schau' Dir mal die einfachen Wege an. Öffne den I-Explorer und geh' unter Extras->Internetoptionen.
Dort kann man den Pfad zu dem Cookie-Ordner ändern. Auch wenn er richtig anzeigt wird, änder den Pfad zu deinem gewünschten Ziel. Windows macht des öfteren unerklärlichen Sch***. Wie sagte so schön der Prof aus I Robot: ... die vielen irrationalen Fehler der Computer ließen die Frage aufkommen, ob Maschinen einen eigenen Willen haben ... (oder so ähnlich)
Ich hoff' es hilft Dir
Simon
Hallo Simon,
Zu Deinem Problem:
Ich habs mir jetzt mal genauer angeschaut.
Mach's mal nicht so kompliziert und schau'
Dir mal die einfachen Wege an. Öffne
den I-Explorer und geh' unter
Extras->Internetoptionen.
Dort kann man den Pfad zu dem Cookie-Ordner
ändern.
Wo?
Meinst Du bei Allgemein - Temporäre Internetdateien - Einstellungen... ?
Zu Deinem Problem:
Ich habs mir jetzt mal genauer angeschaut.
Mach's mal nicht so kompliziert und schau'
Dir mal die einfachen Wege an. Öffne
den I-Explorer und geh' unter
Extras->Internetoptionen.
Dort kann man den Pfad zu dem Cookie-Ordner
ändern.
Meinst Du bei Allgemein - Temporäre Internetdateien - Einstellungen... ?
Hi Daniel,
jop. und dann auf 'ordner verschieben'. dann kommt ein fenster, wo man dann den ordner auswählen kann. Wieso? hast du das schon ausprobiert und hat nich' geklappt? hört sich so an.
Grüßle Simon
jop. und dann auf 'ordner verschieben'. dann kommt ein fenster, wo man dann den ordner auswählen kann. Wieso? hast du das schon ausprobiert und hat nich' geklappt? hört sich so an.
Grüßle Simon
Hallo,
ja das bringt leider nichts...in der Zwischenzeit
befindet sich alles, d.h. Cookies + Temporary Internet Files
%userprofile%\Lokale Einstellungen\Temp ...
Gleichzeitig benutzt der IE auch noch
%userprofile%\Lokale Einstellungen\Temporary Internet Files
Dort allerdings ohne die 4 Unterordner - der Cache liegt dort einfach zusätzlich.
Wenn ich den Ort für den Cache - wie oben beschrieben -
ändere, meldet Windows mich ab, kann ich nicht unterbrechen.
Nachdem ich mich wieder anmelde ist die gleiche Einstellung wie zuvor.
ja das bringt leider nichts...in der Zwischenzeit
befindet sich alles, d.h. Cookies + Temporary Internet Files
%userprofile%\Lokale Einstellungen\Temp ...
Gleichzeitig benutzt der IE auch noch
%userprofile%\Lokale Einstellungen\Temporary Internet Files
Dort allerdings ohne die 4 Unterordner - der Cache liegt dort einfach zusätzlich.
Wenn ich den Ort für den Cache - wie oben beschrieben -
ändere, meldet Windows mich ab, kann ich nicht unterbrechen.
Nachdem ich mich wieder anmelde ist die gleiche Einstellung wie zuvor.
Hi Daniel,
kann es sein, dass du
1. Server-gespeicherte Profile verwendest,
2. Kürzlich ein Samba-Update von einer Version vor 3.0.11 auf die 3.0.20b durchgeführt hast,
3. auf den Problematischen Rechnern den Internet Explorer in einer Version kleiner als 6 einsetzt?
Ich habe nämlich gerade ein ähnliches Problem gehabt und habe nach längerem Debugging und Testen folgendes rausbekommen: (war win2000, aber vielleicht hilft das ja auch weiter)
1. Samba liefert den Clients seit Version 3.0.11 das Schreibschutz-Flag für Ordner innerhalb eines Shares bei dem der smb.conf-Parameter "profile acls = yes" gesetzt ist (wie das [profiles] share mit den user-Profilen).
2. Der Internet Explorer verhält sich folgendermaßen:
a) er schaut die Attribute von %userprofile%\Cookies an
b) Wenn das Schreibschutz-Flag gesetzt ist, ignoriert er diesen Ordner und versucht es mit %SystemRoot%\Cookies (will das ggf auch anlegen).
c) Schlägt auch das fehl (kein admin oder so), so gibt IE 5.0 auf (und ich denke auch der IE 5.5) und speichert gar keine Cookies.
d) Der IE 6.0 aber speichert die Cookies dann in
%userprofile%\Lokale Einstellungen\Temp\Cookies
(wird erzeugt, falls nötig).
Das Problem zu lösen ist ein bisschen vertrackt: Du brauchst "profile acls = yes",
damit der Domänen-Logon klappt. Wenn du willst, dass in %userprofile%\Cookies
gespeichert wird, dann gehe auf eine Samba-Version kleiner als 3.0.11 oder
schmeiss die verantwortliche Passage aus dem Samba-Quellcode raus (das werde
ich tun). Ansonsten nimm einfach überall IE6. Oder gleich einen richtigen Browser:
firefox ...
Gruß, Michael
kann es sein, dass du
1. Server-gespeicherte Profile verwendest,
2. Kürzlich ein Samba-Update von einer Version vor 3.0.11 auf die 3.0.20b durchgeführt hast,
3. auf den Problematischen Rechnern den Internet Explorer in einer Version kleiner als 6 einsetzt?
Ich habe nämlich gerade ein ähnliches Problem gehabt und habe nach längerem Debugging und Testen folgendes rausbekommen: (war win2000, aber vielleicht hilft das ja auch weiter)
1. Samba liefert den Clients seit Version 3.0.11 das Schreibschutz-Flag für Ordner innerhalb eines Shares bei dem der smb.conf-Parameter "profile acls = yes" gesetzt ist (wie das [profiles] share mit den user-Profilen).
2. Der Internet Explorer verhält sich folgendermaßen:
a) er schaut die Attribute von %userprofile%\Cookies an
b) Wenn das Schreibschutz-Flag gesetzt ist, ignoriert er diesen Ordner und versucht es mit %SystemRoot%\Cookies (will das ggf auch anlegen).
c) Schlägt auch das fehl (kein admin oder so), so gibt IE 5.0 auf (und ich denke auch der IE 5.5) und speichert gar keine Cookies.
d) Der IE 6.0 aber speichert die Cookies dann in
%userprofile%\Lokale Einstellungen\Temp\Cookies
(wird erzeugt, falls nötig).
Das Problem zu lösen ist ein bisschen vertrackt: Du brauchst "profile acls = yes",
damit der Domänen-Logon klappt. Wenn du willst, dass in %userprofile%\Cookies
gespeichert wird, dann gehe auf eine Samba-Version kleiner als 3.0.11 oder
schmeiss die verantwortliche Passage aus dem Samba-Quellcode raus (das werde
ich tun). Ansonsten nimm einfach überall IE6. Oder gleich einen richtigen Browser:
firefox ...
Gruß, Michael
Hi Daniel,
kann es sein, dass du
1. Server-gespeicherte Profile verwendest,
ja genau - hatte ich hoffentlich geschrieben...kann es sein, dass du
1. Server-gespeicherte Profile verwendest,
2. Kürzlich ein Samba-Update von einer
Version vor 3.0.11 auf die 3.0.20b
durchgeführt hast,
ja stimmt auch - aber (wie mir in der Zwischenzeit aufgefallen ist) trat der FehlerVersion vor 3.0.11 auf die 3.0.20b
durchgeführt hast,
zuerst in einer anderen Domäne auf:
Samba 3.xx mit Windows 2000 SP4 IE6
xx < 20 kann jetzt aber nicht genau sagen welche Version, vermutlich .11
habe gerade keinen Zugriff...
Nachtrag:bSamba version 3.0.9-2.3-SUSE
Später trat der Fehler auch meiner Domäne auf:
Workstation mit XP Pro SP1, in Domäne an Samba (3.0.20b-SerNet-SuSE)
(bzw Fehler auch schon in 3.0.11 - aktuellstes Update von SuSE über YOU,
bin mir über die Versionsnummer nicht 100% sicher)
3. auf den Problematischen Rechnern den
Internet Explorer in einer Version kleiner
als 6 einsetzt?
siehe 2.Internet Explorer in einer Version kleiner
als 6 einsetzt?
Ich habe nämlich gerade ein
ähnliches Problem gehabt und habe nach
längerem Debugging und Testen folgendes
rausbekommen: (war win2000, aber vielleicht
hilft das ja auch weiter)
1. Samba liefert den Clients seit Version
3.0.11 das Schreibschutz-Flag für
Ordner innerhalb eines Shares bei dem der
smb.conf-Parameter "profile acls =
yes" gesetzt ist (wie das [profiles]
share mit den user-Profilen).
ähnliches Problem gehabt und habe nach
längerem Debugging und Testen folgendes
rausbekommen: (war win2000, aber vielleicht
hilft das ja auch weiter)
1. Samba liefert den Clients seit Version
3.0.11 das Schreibschutz-Flag für
Ordner innerhalb eines Shares bei dem der
smb.conf-Parameter "profile acls =
yes" gesetzt ist (wie das [profiles]
share mit den user-Profilen).
Ja jetzt wo Du es sagst,
Mir ist immer mal wieder der Schreibschutz im Eigenschaften-Fenster
aufgefallen...
2. Der Internet Explorer verhält sich
folgendermaßen:
a) er schaut die Attribute von
%userprofile%\Cookies an
b) Wenn das Schreibschutz-Flag gesetzt ist,
ignoriert er diesen Ordner und versucht es
mit %SystemRoot%\Cookies (will das ggf auch
anlegen).
anfangs versuchte er dort die Cookies abzulegen...folgendermaßen:
a) er schaut die Attribute von
%userprofile%\Cookies an
b) Wenn das Schreibschutz-Flag gesetzt ist,
ignoriert er diesen Ordner und versucht es
mit %SystemRoot%\Cookies (will das ggf auch
anlegen).
c) Schlägt auch das fehl (kein admin
oder so), so gibt IE 5.0 auf (und ich denke
auch der IE 5.5) und speichert gar keine
Cookies.
IE 6 bei mir auch - unter W2K und XP SP1oder so), so gibt IE 5.0 auf (und ich denke
auch der IE 5.5) und speichert gar keine
Cookies.
d) Der IE 6.0 aber speichert die Cookies
dann in
%userprofile%\Lokale
Einstellungen\Temp\Cookies
(wird erzeugt, falls nötig).
Ja aber bei mir erst nach?dann in
%userprofile%\Lokale
Einstellungen\Temp\Cookies
(wird erzeugt, falls nötig).
keine Ahnung... irgendwann hat er sie dort abgelegt,
vielleicht nachdem ich den Schreibschutz für %userprofile% mal in den Eigenschaften
deaktiviert hatte...da er mir aufgefallen ist - mir aber nichts dabei gedacht hatte.
Das Problem zu lösen ist ein bisschen
vertrackt: Du brauchst "profile acls =
yes",
damit der Domänen-Logon klappt. Wenn du
willst, dass in %userprofile%\Cookies
gespeichert wird, dann gehe auf eine
Samba-Version kleiner als 3.0.11 oder
schmeiss die verantwortliche Passage aus dem
Samba-Quellcode raus (das werde
ich tun).
Weisst Du warum ab 3.0.11 die Schreibschutz-Flagvertrackt: Du brauchst "profile acls =
yes",
damit der Domänen-Logon klappt. Wenn du
willst, dass in %userprofile%\Cookies
gespeichert wird, dann gehe auf eine
Samba-Version kleiner als 3.0.11 oder
schmeiss die verantwortliche Passage aus dem
Samba-Quellcode raus (das werde
ich tun).
Geschichte so verwendet wird?
Ansonsten nimm einfach
überall IE6. Oder gleich einen
richtigen Browser:
firefox ...
Oh ja der IE als Browser...überall IE6. Oder gleich einen
richtigen Browser:
firefox ...
sag das mal denen die eine Anwendung entwickeln, die nur mit dem IE läuft!
Firefox hatte ich auch als Notlösung angeboten,
wird aber nicht angenommen ... bzw. funktioniert diese eine wichtige "Anwendung"
nur mit dem IE.
Vielen Dank für die ergiebige Antwort!
Moin,
Hier der entsprechende Auszug aus dem Samba-Changelog:
schnipp ============================
r3811 | vlendec | 2004-11-17 16:56:47 +0100 (Mi, 17 Nov 2004) | 12 lines
Believe it or not, but this patch seems to be necessary. If someone sets a
folder icon in the start menu and saves the profile on a samba server, after
logging in again this setting is gone. Why is this? The folder for which the
icon is set must have the read only flag set. If it is not set, the
desktop.ini file (the file containing the icon reference) inside that folder
is ignored.
lp_profile_acls is a hack for such a situation, so overload this parameter
with another profile-related hack.
Volker
schnapp ========================
Gruß, Michael
Weisst Du warum ab 3.0.11 die Schreibschutz-Flag Geschichte so verwendet wird?
Hier der entsprechende Auszug aus dem Samba-Changelog:
schnipp ============================
r3811 | vlendec | 2004-11-17 16:56:47 +0100 (Mi, 17 Nov 2004) | 12 lines
Believe it or not, but this patch seems to be necessary. If someone sets a
folder icon in the start menu and saves the profile on a samba server, after
logging in again this setting is gone. Why is this? The folder for which the
icon is set must have the read only flag set. If it is not set, the
desktop.ini file (the file containing the icon reference) inside that folder
is ignored.
lp_profile_acls is a hack for such a situation, so overload this parameter
with another profile-related hack.
Volker
schnapp ========================
Gruß, Michael
Hallo nochmal,
ich habe Pakete, bei denen das Setzen des Schreibschutz-Flags deaktiviert ist auf den ftp-server gelegt, einmal als Quell-RPM:
ftp://ftp.sernet.de/pub/samba/src/samba3-3.0.20b-24.norbits.src.rpm
und dann Binärpakete für SuSE Linux 8.2 (sollten auch für 9.0) noch gehen unter
ftp://ftp.sernet.de/pub/samba/suse/suse82/norbits/
Die in dem Changelog-Zitat beschriebenen Korrekturen sind damit wieder aufgehoben, aber man kann wenigstens Surfen... Vielleicht wird das in Zukunft noch ausgebaut.
Gruß, Michael
ich habe Pakete, bei denen das Setzen des Schreibschutz-Flags deaktiviert ist auf den ftp-server gelegt, einmal als Quell-RPM:
ftp://ftp.sernet.de/pub/samba/src/samba3-3.0.20b-24.norbits.src.rpm
und dann Binärpakete für SuSE Linux 8.2 (sollten auch für 9.0) noch gehen unter
ftp://ftp.sernet.de/pub/samba/suse/suse82/norbits/
Die in dem Changelog-Zitat beschriebenen Korrekturen sind damit wieder aufgehoben, aber man kann wenigstens Surfen... Vielleicht wird das in Zukunft noch ausgebaut.
Gruß, Michael
Hallo,
ich bin bisher nicht dazu gekommen...
aber die Änderung scheint doch eine "Verschlimmbesserung" zu sein?!
zumindest für alle die Server gespeicherte Profile einsetzen...
deswegen gab es hier auch Probleme mit Ordnern auf dem Desktop der User, die nicht
oder unvollständig synchronisiert wurden...
ich bin bisher nicht dazu gekommen...
aber die Änderung scheint doch eine "Verschlimmbesserung" zu sein?!
zumindest für alle die Server gespeicherte Profile einsetzen...
deswegen gab es hier auch Probleme mit Ordnern auf dem Desktop der User, die nicht
oder unvollständig synchronisiert wurden...
