Closed Bug 309323 Opened 19 years ago Closed 7 years ago

Firefox, Mozilla and Camino don't run with SMB-Mounted Home-directorys OSX10.3.9

Categories

(Firefox :: Shell Integration, defect)

All
macOS
defect
Not set
major

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: gothe05, Unassigned)

Details

Attachments

(1 file, 1 obsolete file)

User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.7.11) Gecko/20050729 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.7.11) Gecko/20050729 Our Macintosh Lab (1000 Students, 40 macs, OSX 10.3.9) identifies Users at a Active Directory Domain and then mount the Homedirectory from a Linux SMB-Server. Firefox, Mozilla and Camino don't run with SMB-Mounted Homedirectories. There are no local Directories for these Users. When it starts it tell me, that the Preferences are in use or it has Problems with profile location. May be a Character-Problem between OSX and Samba ?? Permissions are checked. All other Programms (Adobe, Macromedia, Quark, Apple) are working. Reproducible: Always Steps to Reproduce: 1.use a SMB-mounted Homedirectory on OSX 2.start Firefox (mozilla, Camino) 3. Actual Results: Window with Error, Preferences in use or Problem with Prefs Expected Results: running the preferences are created in ~user/Library/Application Support/Firefox/Profiles
See Bug 201506 "Missing profile causes crash while trying to access bookmarks [@ -[BookmarksDataSource outlineView:numberOfChildrenOfItem:]]"
This is going to be hard to debug because not many of the core Mac programmers will have access to such a network setup. To give us a shot at solving this, please do the following: 1. Open "Console.app" 2. Lauch Firefox or Camino in the problematic situation 3. Copy any messages that get spit into the console during application launch and failure, post them on this bug. If there are a lot of them, please put them in a text file and put them up as attachments. I've heard about issues like this before, but I don't know enough to know if we have a bug on this particular issue around.
smb-mounted Homedirectories does NOT SUPPORT LINKS !!! If I try to produce a symbolic Link inside the smb-mounted Homedirectory, that point to a File on a local Harddisk OR to a File on the smb-mounted FIlesystem Error-message is: e.g. ln -s test test1 ln: test1: Operation not supported /var/log/system.log show me, that camino try to make links.
(In reply to comment #3) > smb-mounted Homedirectories does NOT SUPPORT LINKS !!! Could you check whether the SMB file system supports soft (symbolic) links when mounted by linux or a BSD variant of your choice? What happens in the case of an SMB file system exported by the Microsoft SMB server? It might be that there is no quick answer to your problem, but perhaps there should be a more specific error message. Would you be able to create a RAM disk (writeable Disk Image), or USB filesystem for the profile directory?
It may be the SMB-client on Macintosh OSX :-( When I mount the directory from a Computer with SUSE 9 Linux with "mount -t smbfs -o username=joachim,password=xxxxx //projekte/joachim test" I am able to make sym- and hard-links, when I mount it from Macintosh OSX (10.3.9), I am NOT able to make symlinks. The smb-client of OSX (10.3.9) is not able to produce links.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Sean, attachment 210328 [details] shows a ktrace of the firefox sh script, not the firefox-bin (or whatever it's called on Mac OS X) executable launched by that script. If you trace that process, you'll probably see failing symlink system calls. Such a trace could be helpful in developing a fix to this bug. /be
Sorry, I'm not a programmer. I assumed that since the firefox shell script calls firefox-bin that ktrace would capture its output also. Nope. Here is output from firefox-bin.
(In reply to comment #7) > Created an attachment (id=210329) [edit] > ktrace showing Firefox choking on not being able to create a symlink on an > smb-mounted fs. This looks to file on FC3 like a zip, not a bzip2, but FC3's unzip can't grok it. Can you show just the failing symlink calls and some surrounding context? Thanks, /be
(In reply to comment #8) > This looks to file on FC3 like a zip, not a bzip2, but FC3's unzip can't grok > it. Can you show just the failing symlink calls and some surrounding context? > Thanks, > > /be > Sorry....I used Winzip 10's bzip option. I've reposted it bz2'd on a Linux box.
Attachment #210329 - Attachment is obsolete: true
Bzip'd it on a Linux box. Damn WinZip.... ;-)
Comment on attachment 210445 [details] ktrace showing Firefox choking on not being able to create a symlink on an smb-mounted fs. Correcting MIME type per comment 9.
Attachment #210445 - Attachment mime type: application/octet-stream → application/x-bzip2
EOPNOTSUPP Operation not supported on socket Great. Why? Is Apple going to fix this? Can an opendarwin.org bug be filed, if one isn't on file already? In the mean time, we have a second bug (or third: AFS [bug 318801] and NFS [not yet split out from the AFS bug]) on broken remote filesystem locking. This one is different from bug 318801, however: that bug has to-do with fcntl getting EAGAIN. Here we have symlink not supported. Catch 22. We could fail soft if EOPNOTSUPP, since the symlink is created after the fcntl lock has been acquired, only to interoperate with old versions. IIRC -- roc pls. check my sanity. /be
I think we could just copy this UNIX code to use in OSX as well: http://lxr.mozilla.org/seamonkey/source/profile/dirserviceprovider/src/nsProfileLock.cpp#545 545 // If the symlink failed for some reason other than it already 546 // exists, then something went wrong e.g. the file system 547 // doesn't support symlinks, or we don't have permission to 548 // create a symlink there. In such cases we should just 549 // continue because it's unlikely there is an old build 550 // running with a symlink there and we've already successfully 551 // placed a fcntl lock. 552 if (rv != NS_ERROR_FILE_ACCESS_DENIED) 553 rv = NS_OK;
(In reply to comment #13) > I think we could just copy this UNIX code to use in OSX as well: > http://lxr.mozilla.org/seamonkey/source/profile/dirserviceprovider/src/nsProfileLock.cpp#545 > 545 // If the symlink failed for some reason other than it already > 546 // exists, then something went wrong e.g. the file system > 547 // doesn't support symlinks, or we don't have permission to > 548 // create a symlink there. In such cases we should just > 549 // continue because it's unlikely there is an old build > 550 // running with a symlink there and we've already successfully > 551 // placed a fcntl lock. > 552 if (rv != NS_ERROR_FILE_ACCESS_DENIED) > 553 rv = NS_OK; > This code IS in v1.5 and v1.5.0.1. And, according to the build info for Mac OS X, XP_UNIX is defined. Soooo....Again, I'm not a real programmer, and I am confused.
It's not built for OSX ... http://lxr.mozilla.org/seamonkey/source/profile/dirserviceprovider/src/nsProfileLock.cpp#456 has "#if defined(XP_MACOSX)", and below is "#elif defined(XP_UNIX)". Only the first part is built for OSX.
I've no idea if my setup is similar to a AD setup, but when I create a shared folder on one of my XP machines and connect to it via SMB I see similar problems. When starting Firefox following errors are shown in the Error Console: Error: [Exception... "Component returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]" nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)" location: "JS frame :: file:///Applications/Shiretoko.app/Contents/MacOS/components/nsPlacesDBFlush.js :: nsPlacesDBFlush :: line 81" data: no] Source File: file:///Applications/Shiretoko.app/Contents/MacOS/components/nsPlacesDBFlush.js Line: 81 Error: uncaught exception: [Exception... "Component returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]" nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)" location: "JS frame :: file:///Applications/Shiretoko.app/Contents/MacOS/modules/utils.js :: anonymous :: line 106" data: no] Error: uncaught exception: [Exception... "Component returned failure code: 0x8007000e (NS_ERROR_OUT_OF_MEMORY) [nsIDocShellHistory.useGlobalHistory]" nsresult: "0x8007000e (NS_ERROR_OUT_OF_MEMORY)" location: "JS frame :: chrome://browser/content/browser.js :: prepareForStartup :: line 1075" data: no]
Hardware: PowerPC → All
Version: unspecified → Trunk
(In reply to comment #16) Not this bug. Sounds similar to bug 417037 though.
Not a shell integration bug and no activity in years so resolving -> incomplete
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: