Inzwischen lautet der Link so:
Suche: Textsuchhe in mehreren Tabs
Beiträge von bauinformatiker
-
-
-
[%HOMEDRIVE%\%HOMEPATH%\appdata\roaming\mozilla\firefox\Profiles\]
Geht eben so nicht
Warum nicht?
Gruß Ingo
echo %homedrive%
ist auf meinem Windows 10 Pro nicht definiert.echo %homepath%
auch nicht.
%userprofile%
kommt dem wohl nahe ... -
c:\users\USERNAME\appdata\roaming\mozilla\firefox\Profiles\
entspricht %appdata%\Mozilla\Firefox\Profiles\ dort sind die Profilordner von Firefox
Genau!
Sorry, ich war verwirrt, weil %appdata% auf den OrdnerC:\Users\<username>\AppData\Roaming
zeigt. Vielleicht hätte ich einfach gleich nur den Nutzernamen anonymisieren sollen.
An dem Rechner, an dem der Fehler auftrat, haben wir "ganz normale" Server-basierte-Profile. Diese werden beim Rechnerstart auf den Rechner synchronisiert. Ändert ihr die Verknüpfungen, dass "...\AppData\Roaming" und "...\AppData\Local\" auf einen Ordner in einer Netzwerkfreigabe zeigen? -
Nach einem Windows (!) Update behauptet FF ESR68.2.0 an 2 Rechnern, dass das Profil mit einem neueren FF geöffnet wurde (was definitiv nicht richtig ist, weil User dort keine Admin Rechte hatten) und legt automatisch ein neues Profil im Ordner
%appdata%\Local\Mozilla\Firefox\Profiles\
an. Ich konnte jeweils die Bookmarks aus dem alten Profil in das neue kopieren (places.sqlite und favicons.sqlite). An Firefox wurde einige Wochen lang nichts geändert.
-
Wenn du der Admin bist, hast du im geschilderten Fall eine Baustelle, die es zu beheben gilt... wenn nicht, gib dem zuständigen Admin den Hinweis, das er "gschlampert" hat...
Wenn du die Rechtevergabe meinst, die bestimmt hier nicht der Admin. Ansonsten gilt hier die Policy Security-Updates möglichst schnell bereit zu stellen. Wenn diese dann fehlerhaft sind, werden sie zurück gezogen. Leider ist es schwer an Informationen ran zu kommen, unter welchen Umständen der Fehler auftritt.
Sowohl ein Upgrade über die SW-Verteilung als auch über die FF-interne Updatefunktion sollte klappen. Also bitte bleibt konstruktiv! -
dann schaue unter about:profiles nach...
ggf. wurde bei der Installation ein neues Profil erstellt. Dies ist bei neueren Versionen so, wenn diese neu installiert und nicht via UpDate aktualisiert werden.
BTW: ESR wird hier nicht genutzt, von daher kann ich zu dieser Produktlinie keine Auskunft geben...
Ich weiß, die alten Profile waren noch vorhanden. Leider kann ich nicht mehr genau nachvollziehen, ob das Problem durch ein Update über die Softwareverteilung kam oder ob besonders "schlaue" User sich die EXE selbst geholt haben und dann auf die Schnauze fielen. Laut den Logfiles eher zweiteres. "Eigentlich" ist den Usern verwehrt ohne Admin-Rechte Firefox upzudaten. Entweder greift diese Konfiguration nicht mehr oder sie haben das Hintertürchen "lokaler Admin" genutzt ... -
Bei Borncity wird schon fleißig diskutiert und auch in unserer Firma gab's Probleme.
https://www.borncity.com/blog/2019/12/0…eme-beim-updateWir verwenden keine Addons zur Konfiguration und haben auch im aktuellen Update diese nicht "angerührt". Das Problem war dann, dass die User in der ESR68.3.0 ihr FF Profil nicht mehr gesehen haben.
-
Zitat von .Hermes
Kein Browser dieses Planeten öffnet einen Port 80 für eine ausgehende Verbindung. Das kann ja auch nicht funktionieren, weil jeder Web-Server den Port 80 für eingehende Verbindungen öffnet.In der `firewall.cpl`sind default-mäßg ausgehende Ports offen. Der Admin kann das ändern, dann können nur bestimmte Programme im Web surfen. Das ist mir zu viel "Gängelei" und Aufwand.
Zitat von .Hermes
Ich habe ja noch nie viel von Persönlichen Firewalls gehalten - diese Klamotten sind nicht sicher.
Hilfreich ist es, wenn nicht jedes Programm plötzlich Serverdienste nach der Installation anbietet, die man vielleicht nicht vermutet hat. Dass es Wege gibt, dies zu umgehen, mag sein. Aber zumindest bei Inbound-Traffic ist das denke ich nicht trivial.Zitat von .Hermes
Aber wenn ein profaner Installer die Regeln für sich zurecht biegen kann, geht das letzte Vertrauen verloren.Kann er nicht. Ein User mit Admin-Rechten muss die neue Regel bestätigen oder halt vorher schon freigeben. Sowas will man im Unternehmen erst gar nicht sehen. Und wenn dann (weil der User ja gar nicht zulassen kann), die neue Regel abgelehnt wird, sollte der Browser ja trotzdem browser können
Zitat von .HermesNur so soll es ja wirklich sein.
Genau, und so ist es auch
-
Danke für die Erklärung! Port 443 hatte ich glatt unterschlagen
Die "Personal Firewall" von Windows (`firewall.cpl`) ist afaik so defaultmäßig konfiguriert, dass sich Programme auf dem PC mit externen Servern verbinden können ("ausgehend"/"inbound"), aber selbst keinen Server-Dienste (meist Ports <1024, "eingehend"/"outbound") nach außen hin anbieten können. Und genau das will unser lieber Firefox 36 machen und deshalb kommt das Popup während der Installation.
-
Als Admin muss ich nicht alles in der Firewall aufmachen, was ein Programm verlangt, sondern habe ich nur das zu öffnen, was in der Sicherheitsrichtlinie frei gegeben ist. Das ist dann z.B. für alle Browser Port 80 TCP ausgehend. Wenn ein Browser dann gar nicht mehr funktioniert, dann darf ich nicht deshalb eigenmächtig weitere Ports aufmachen, weder am Perimeterpunkt, noch in der Windows-Firewall.
Sören, vielen Dank für den Bugzilla-Link!
https://bugzilla.mozilla.org/show_bug.cgi?id=1136772Die Leute beschreiben vielleicht besser wie ich genau mein Problem, z.B.
Zitat
Firefox 36 setup is no longer creating the firewall rules during installation.
Instead Firefox 36 (at least on a Win 7 thats joined to a domain) creates 4 rules on its first startup:UDP and TCP, each one for the private and the domain profile.
This is bad news for standard users, they have no permission to add firewall rules.
Firefox 35.0.1 setup created just the rules for private network but even when started while configured for the domain profile there is NO Windows firewall prompt.
If those inbound rules are only required for "Hello" it would be great if we just could turn that feature off during setup when its not used at all. No firewall rules required then.
Ich werde das weiter dort verfolgen und bei Gelegenheit die Portable Version nachmal testen. Leider ist das so zeitraubend, weil ich meinen Rechner immer komplett neustarten muss, nachdem der Browser eingefrohren ist ...
-
Zitat von AngelOfDarkness
Dann ist das doch ein Fall für den Admin sich darum zu kümmern, dass alles gepflegt und auch benötigte Regeln zu Updates in die netzwerkeigene FW eintragen werden sowie das reibungslose Spiel zwischen einer WFW und einer Hardware FW klappt.
Zum Browsen kein weiterer Port benötigt wird und deshlab gibt's auch keine neuen Ports, schon gar nicht EINGEHEND!!!
-
-
Zitat von pencil
Testdurchlauf
- Firefox-Probleme mit dem abgesicherten Modus beheben
mozilla support
Führt das nicht zum Erfolg:
[...]Also der safe-mode reicht nicht aus, um bei mir FF36 ohne Fehler zu benutzen! Erst geht's und dann stockt der Datenverkehr. Irgendwann erscheint dann auch die Mozilla-Absturzmeldung und FF36 versucht neu zu starten. Funktioniert aber nicht, da auch hier der Prozess nicht beendet werden kann. Hab schon nach Logfiles gesucht, wo Hinweise stehen könnten, aber keine Logs gefunden.
Der Clou ist, dass die Anwender beim ersten Start der neuen Version alle das Popup mit der Frage zum aktivieren der neuen Firewall-Regel sehen würden. Sowas geht natürlich in einem Unternehmen nicht, und Adminrechte hat nat. auch keiner.
Irgendwer hatte hier geschrieben, dass man eine "Windows-Firewall" braucht, wenn man Internetzugang eine FW hat. Das stimmt nicht und die beiden arbeiten ja auch total unterschiedlich.
Morgen schau ich mit dem Portable FF weiter ...
- Firefox-Probleme mit dem abgesicherten Modus beheben
-
Zitat von Fox2Fox
Welche Providerbox ist angeschlossen?
Falls es eine FritzBox ist:
Bin hier in einem Unternehmen. Wir haben irgendeine FW auf FreeBSD-Basis.
-
Zitat von .Hermes
Scheint eh eine sehr intelligente PFW zu sein.
Auf dem PC ist Win7 64bit und die Firewall ist die Windows-FW.
Doof ist, dass eben auch wenn ich nachträglich die deaktivierten Regeln in der FW erlaube, FF nicht richtig funktioniert. Z.B. konnte ich ca. 2min lang surfen, dann gab's einfach keinen Datenverkehr mehr auf der Netzwerkkarte. Andere Browser laufen wunderbar.
Dazu halt das Problem, dass sich Firefox nicht mehr richtig beenden lässt, weil nach dem schließen aller Fenster der Prozess "firefox.exe" als Leiche im Taskmanager bleibt und sich durch nichts, was mir bekannt ist, beenden läßt.
-
Jetzt ist die final von FF36 draußen und ich habe das selbe Problem...
Ich schau mal, ob https://bugzilla.mozilla.org/show_bug.cgi?id=1103833
hilfreich ist. Da sieht man ja die Nadel vor lauter Heu nicht -
Ja, sowas nervt!
Ich habe beim Dialog der WFW die Freigabe verweigert. FF36 lädt jetzt bei mir gar keine Webseiten.
Beim Beenden werden die Fenster geschlossen, aber der Prozess im Taskmanager bleibt. Auch manuell und mit vollen Admin-Rechten lässt er sich nicht killen. Neustart ist die einzige Lösung.
vgl.
https://www.camp-firefox.de/forum/posting.…ly&f=7&t=111448