Αναζήτηση στην υποστήριξη

Προσοχή στις απάτες! Δεν θα σας ζητήσουμε ποτέ να καλέσετε ή να στείλετε μήνυμα σε κάποιον αριθμό τηλεφώνου ή να μοιραστείτε προσωπικά δεδομένα. Αναφέρετε τυχόν ύποπτη δραστηριότητα μέσω της επιλογής «Αναφορά κατάχρησης».

Μάθετε περισσότερα

Firefox profile on user data partition inaccessible when Firefox running on Windows 10 Technical Preview as virtualized by VMware Workstation 11.0.

  • 1 απάντηση
  • 1 έχει αυτό το πρόβλημα
  • 7 προβολές
  • Τελευταία απάντηση από guigs

more options

This is how my family stores their respective Firefox profiles on the family computer:

********** [General] StartWithLastProfile=1 [Profile0] Name=default IsRelative=0 Path=E:\<user>\Mozilla\ff\ff1 ********** The "E:\" partition is our user data partition. We keep Mozilla profiles there for two reasons: 1. Ease of backup. No need for YET ANOTHER special back-up rule. 2. All of the operating systems on the machine (we usually are running several via multi-boot) can use the same profiles, which hence do not become unsynchronized across the various operating systems. We do the same thing for Thunderbird: ********** [General] StartWithLastProfile=1 [Profile0] Name=Bellsouth IsRelative=0 Path=E:\<user>\Mozilla\tb\tb1 ********** So now we're evaluating Windows 10 Technical Preview... not on bare metal, but rather as virtualized by VMware Workstation 11.0, which treats partitions other than C: as mapped network drives. Hence, our profiles now look like: ********** [General] StartWithLastProfile=1 [Profile0] Name=default IsRelative=0 Path=\\vmware-host\Shared Folders\E\<user>\Mozilla\ff\ff1 ********** [General] StartWithLastProfile=1 [Profile0] Name=Bellsouth IsRelative=0 Path=\\vmware-host\Shared Folders\E\<user>\Mozilla\tb\tb1 ********** Note that VMware Workstation maps external partitions via "\\vmware-host\Shared Folders\<drive letter>". By the way, apps running on Windows 10 TP virtualized in general have no problems accessing our E: partition in this manner. Thunderbird is able to find and use the non-relative partitions without issue. However, Firefox fails to do so. After experimenting a bit, this is what appears to be happening: 1. Firefox appears in the Process List for less than one second and then disappears. 2. Firefox generates the error: "Firefox is already running, but is not responding. The old Firefox process must be closed to open a new window." 3. Click the "Close Firefox" button. 4. Firefox generates the error: "Your Firefox profile cannot be loaded. It may be missing or inaccessible." Well, that last error is infamous... but we learned long ago how to find/fix missing profiles. This is something else altogether. Is the problem simply that Firefox cannot have profiles on mapped network drives... but Thunderbird can? Or is there some other issue lurking here? Thanks in advance for your assistance. Best regards, ...milo47 P.S. I'm writing this on Firefox on Windows 7 / SP1 / Pro / x64 on bare metal... not under Windows 10... so the Troubleshooting Information is misleading. Obviously, I cannot run Firefox yet on Windows 10!

But, for what it's worth, I don't use many plug-ins, and the version of Firefox on Windows 10 is absolutely up-to-date.

This is how my family stores their respective Firefox profiles on the family computer: <nowiki>********** [General] StartWithLastProfile=1 [Profile0] Name=default IsRelative=0 Path=E:\<user>\Mozilla\ff\ff1 ********** The "E:\" partition is our user data partition. We keep Mozilla profiles there for two reasons: 1. Ease of backup. No need for YET ANOTHER special back-up rule. 2. All of the operating systems on the machine (we usually are running several via multi-boot) can use the same profiles, which hence do not become unsynchronized across the various operating systems. We do the same thing for Thunderbird: ********** [General] StartWithLastProfile=1 [Profile0] Name=Bellsouth IsRelative=0 Path=E:\<user>\Mozilla\tb\tb1 ********** So now we're evaluating Windows 10 Technical Preview... not on bare metal, but rather as virtualized by VMware Workstation 11.0, which treats partitions other than C: as mapped network drives. Hence, our profiles now look like: ********** [General] StartWithLastProfile=1 [Profile0] Name=default IsRelative=0 Path=\\vmware-host\Shared Folders\E\<user>\Mozilla\ff\ff1 ********** [General] StartWithLastProfile=1 [Profile0] Name=Bellsouth IsRelative=0 Path=\\vmware-host\Shared Folders\E\<user>\Mozilla\tb\tb1 ********** Note that VMware Workstation maps external partitions via "\\vmware-host\Shared Folders\<drive letter>". By the way, apps running on Windows 10 TP virtualized in general have no problems accessing our E: partition in this manner. Thunderbird is able to find and use the non-relative partitions without issue. However, Firefox fails to do so. After experimenting a bit, this is what appears to be happening: 1. Firefox appears in the Process List for less than one second and then disappears. 2. Firefox generates the error: "Firefox is already running, but is not responding. The old Firefox process must be closed to open a new window." 3. Click the "Close Firefox" button. 4. Firefox generates the error: "Your Firefox profile cannot be loaded. It may be missing or inaccessible." Well, that last error is infamous... but we learned long ago how to find/fix missing profiles. This is something else altogether. Is the problem simply that Firefox cannot have profiles on mapped network drives... but Thunderbird can? Or is there some other issue lurking here? Thanks in advance for your assistance. Best regards, ...milo47 </nowiki> P.S. I'm writing this on Firefox on Windows 7 / SP1 / Pro / x64 on bare metal... not under Windows 10... so the Troubleshooting Information is misleading. Obviously, I cannot run Firefox yet on Windows 10! But, for what it's worth, I don't use many plug-ins, and the version of Firefox on Windows 10 is absolutely up-to-date.

Τροποποιήθηκε στις από το χρήστη cor-el

Όλες οι απαντήσεις (1)

more options

Currently there is a limited amount of support for Firefox on Windows 10 until is comes out officially later this year. However since you are having issues with the network drive the path looks good. You are not using %AppData% since environmental variables do not work.


Though in earlier versions the only successful instance I can find is :