Last Comment Bug 62851 - (samba) file URL (and UNC path) fails to display share level
: file URL (and UNC path) fails to display share level
: arch, testcase
Product: Core
Classification: Components
Component: Networking: File (show other bugs)
: Trunk
: x86 All
P3 enhancement with 11 votes (vote)
: Future
Assigned To: Nobody; OK to take it and work on it
: benc
: Patrick McManus [:mcmanus]
: 229436 236059 (view as bug list)
Depends on:
Blocks: 73003
  Show dependency treegraph
Reported: 2000-12-14 12:45 PST by Prisacari Sergey
Modified: 2015-12-11 07:20 PST (History)
15 users (show)
maxxmozilla: wanted1.9.1?
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

(87.91 KB, image/png)
2009-06-07 15:53 PDT, mohamad
no flags Details

Description User image Prisacari Sergey 2000-12-14 12:45:52 PST
\\natalie - doesn't work
\\natalie\incoming - work
NetBIOS network
Comment 1 User image Keyser Sose 2000-12-20 01:14:08 PST
Reporter are these local files or remote files? What build are you using? What platform are the files being hosted on etc?
Comment 2 User image Prisacari Sergey 2000-12-20 06:51:49 PST
Platform W2K.
Buils 2000121204
Mozilla doesn't show list of shared folders at Linux, Win9x, WinNT.
If I add shared folder name to host name(e.g. \\natalie\incoming) its contains
are showed correctly.
Comment 3 User image Eric Hodel 2001-01-17 17:00:05 PST
When attempting to list the shares available via NT file sharing (this will work
on win9x or greater) mozilla freezes.  If you have NT you can browse to \\<your
machine name> or if you have 9x you will have to enable file sharing in your
network properties.  (Build 2001011004 WinNT)

It is debatable as to whether we should be able to view NT file shares or not
because 4.x never did.  I recommend marking this bug wontfix or invalid because
Mac and Linux will not be able to view these files without adding extensive code
to the netwerk bits.  Recommended behavior would be displaying an error on a
\\servername\ style URI.

Comment 4 User image benc 2001-05-21 16:11:12 PDT
Open Networking bugs, qa=tever -> qa to me.
Comment 5 User image benc 2001-08-16 02:51:54 PDT
-> file.
Similar to several other bugs.
Comment 6 User image benc 2001-08-22 15:24:47 PDT
Where are you entering this? Is this a HREF link or is this in the location bar?

If I understand what you are asking for, what probably neds to happen is that
the UI you enter the path needs to convert to a file URL. 
Comment 7 User image Prisacari Sergey 2001-08-31 05:32:36 PDT
I entered this lopcation bar
"\\server\incoming" and "file://///server/incoming" works fine,
but both "file://///server" and "\\server" don't work 
Comment 8 User image benc 2001-08-31 10:54:56 PDT

This needs an additional round of definition.
Comment 9 User image benc 2001-09-05 01:45:35 PDT
So this is a "top" level of server bug, subdirectoris work fine, right?

Please let me know if the new summary is accurate. 

Also, does this happen in other platforms?
Comment 10 User image benc 2001-09-05 07:40:56 PDT
Comment 11 User image benc 2001-10-09 12:07:23 PDT
Commercial trunk 2001100403

Same as reporters behavior.
+ arch: This does not work in Comm 4 either, so I am not sure if this is 
desired behavior.
Comment 12 User image Cormac F 2001-10-30 11:26:57 PST
*** Bug 107540 has been marked as a duplicate of this bug. ***
Comment 13 User image Ben Hutchings 2002-04-09 09:44:35 PDT
"\\natalie" is not a valid UNC path and does not represent a shared drive.  In
the UNC path "\\natalie\incoming", "incoming" is a share name, not a
sub-directory name.  You can confirm this by typing "dir \\natalie"
(substituting a locally valid machine name) at a command prompt; it will fail. 
Under Windows 2000, the error message is "The filename, directory name, or
volume label syntax is incorrect."

Windows Explorer seems to handle this as a special case, and that's what
Prisacari seems to want.  That's surely a feature request, not a bug report.

Comment 14 User image Jimmy Sieben 2002-08-12 17:11:52 PDT
I am unable to use file URLs with UNC paths which are in links.

For example, I have a special page with a bunch of links to internal locations,
things like


When I click on one of these links, nothing happens. It works in IE.
Comment 15 User image benc 2002-08-13 17:15:35 PDT
Please look at bug 122022.
Comment 16 User image Doug Turner (:dougt) 2002-10-01 12:56:16 PDT
moving neeti's futured bugs for triaging.
Comment 17 User image benc 2002-10-01 13:22:37 PDT
-> default owner
Comment 18 User image Andrew Hagen 2003-02-21 11:29:13 PST
This would be an enhancement, not a bug. Like comment 3, I recommend wontfix.
Comment 19 User image benc 2003-05-29 20:17:58 PDT
You can't have a SERVER w/o a share. The suggested UNC is invalid.

from a Microsoft site...

A Universal Naming Convention (UNC) name identifies the networked file. The UNC
name consists of a server name and a share name, such as \\SERVER\SHARE.

Would someone VERIFY/WTF if they agree?
Comment 20 User image Andrew Hagen 2003-05-29 21:50:11 PDT
I agree with comment 3 and with Ben. Resolving as wontfix. 
Comment 21 User image benc 2003-06-02 01:20:11 PDT
Comment 22 User image Prisacari Sergey 2003-06-02 02:12:49 PDT
Maybe bad summary has confused you, but originally this bug was about Mozilla
isn't showing list of shares. It is not about Mozilla's support of UNC.
Comment 23 User image Andrew Hagen 2003-06-02 06:51:23 PDT
I found an IETF draft document that suggests:




That draft is at:

Currently, Mozilla does not support the SMB protocol in URIs. 

Listing shares appears to be a small need that would require great effort to
implement. It's not clear why we need a web browser to list SMB shares.
Comment 24 User image benc 2004-01-01 21:34:24 PST
*** Bug 229436 has been marked as a duplicate of this bug. ***
Comment 25 User image benc 2004-09-23 08:00:34 PDT

On my XP system:
IE hands off to Windows Explorer.
I'm not sure how this should work in Mozilla, but it should be reconsidered...

From looking at this a lot more lately, I think the request is pretty
reasonable, especially since we have an "up" link in URL's like this:

This also maybe fixable via bug 13607, because there seems to be a more general
problem about Windows drives just not being displayed well.
Comment 26 User image Brian 'netdragon' Bober 2004-09-23 09:41:02 PDT
*** Bug 73003 has been marked as a duplicate of this bug. ***
Comment 27 User image Brian 'netdragon' Bober 2004-09-23 10:12:51 PDT
Changing OS to ALL. This also affects Linux as nautilus has network browsing. 

> Listing shares appears to be a small need that would require great effort to
> implement. It's not clear why we need a web browser to list SMB shares.

Agreed, and handled best by those writing the actual operating systems. We
should hand off to Explorer on Windows and nautilus on Gnome, or otherwise
whatever application has registered the smb:// protocol on Linux. Can the
registered network browser (Explorer) be overridden on Windows?

There should be no reason, for instance, people wouldn't be going to on Linux.

So the question is, what URIs should we accept...

I have seen sites such as use URIs like: file:///\\netserv and
file://\\netserv which both work in IE and Explorer and do the same thing as

nautilus handles smb:/// to simulate network neighborhood, and smb://netserv to
be the same nas \\netserv is on Explorer

IE and Explorer cannot handle smb://

nautilus cannot handle //netserv or file://///netserv and if you type // in
bash, it will still accept it as the equivalent to /

This is what I believe we should do:

1) We should handle smb:///, passing them off to Explorer as "Network
Neighborhood" and nautilus as smb:///

2) We should handle smb://someserver, passing them off to Explorer as
\\someserver and nautilus as smb://someserver

3) We should convert the special cases file:///\\someserver,
file:///\\someserver, and \\someserver to smb://someserver regardless of
operating system.

Handling //netserv could cause problems because currently, //usr does the same
as /usr in Linux, and the slashes are backwards anyway from the way Windows does
it. file://///usr also works in Linux, along with

This bug is obviously one reason people would need to go back to using IE for
some cases. Mozilla, without much work hand off to the registered handlers on
the operating system.
Comment 28 User image Brian 'netdragon' Bober 2004-09-23 10:20:58 PDT
*** Bug 236059 has been marked as a duplicate of this bug. ***
Comment 29 User image Brian 'netdragon' Bober 2004-09-23 10:35:41 PDT
Btw, I think the summary is hard to understand and will likely not be found (as
demonstrated by bug 236059. Should the summary be changed to "Handle URLs for
samba shares (network neighborhood) and handoff to registered handler"?

Bug 236059 mentioned that sometimes samba shares are linked to using
file://sambaserver/ and that works in IE. Should we handle that, too?
file://sambaserver/ would never be misidentified as a file, right?

Would any of the schemes I mentioned interfere with nfs browsing (I've never
tried NFS)?

I just noticed that although \\netserv doesn't work on Firefox for Windows,
\\netserv\shared works on Firefox for windows and shows the URL as
file://///netserv/shared, which on Linux shows the directory /netserv/shared
created via:

netdragon1:(/)> mkdir netserv
netdragon1:(/)> mkdir netserv/shared

Typing \\netserv\shared on Linux brings you to
because of the automatic Google thing..

Not only does Mozilla not act consistently with IE's scheme, but it also isn't
even consistent with itself.

To summarize, the 5 schemes I mentioned are:
1) smb://netserv
2) smb:/// (equivalent to network neighborhood)
3) \\netserv and \\netserv\shared
4) file://\\netserv and file://\\netserv\shared
5) file://netserv

3,4, and 5 would redirect to 1. 1 would open Explorer or nautilus to the share,
whereas 2 would open Explorer to "Network neighborhood" and nautilus to smb:///
Comment 30 User image benc 2004-10-14 07:33:48 PDT
Brian, please see my comments in your original bug, I think that this bug should
be about shares at the file level, and we should open a new bug, or reopen your
old bug, and make it be only about smb support. We can't do everything you want
via one fix.
Comment 31 User image Pam Greene 2006-02-13 10:42:46 PST
I'm hearing from a user who would very much like us to "Handle URLs for
samba shares (network neighborhood) and handoff to registered handler."  Pardon my ignorance and search failure, but if this bug is about something else, and bug 236059 is a dupe of this one, is there now another place to vote for that?
Comment 32 User image Doug Turner (:dougt) 2007-10-08 16:23:17 PDT
mass reassigning to nobody.
Comment 33 User image Medievalist 2008-04-10 13:23:56 PDT
OK, here's a (hopefully) better bug description.

On Microsoft systems, Firefox & family do not present file URLS in the same way as IE or Opera.  In fact, firefox usually fails silently or without useful error messages.  This is a major flaw for non-programmer users in a Microsoft or Microsoft-compatible (samba) environment.

A Microsoft file share has a root, which functions like the root of a *nix filesystem or the MFD of a more highly evolved file system.  The file reading and writing primitives of the Microsoft Windows family of operating systems can read all parts of a share that are accessible to users, including the root.  File and directory protection mechanisms can be used to prevent or grant access, as you'd expect.

So, as in the previously listed examples, a Microsoft Windows Server (or a linux/BSD/VMS server running samba) can publish a bunch of shares like so:


and so forth.  This is commonplace in the windows world, and samba conforms to this scheme as well.

An end-user running Microsoft Internet Explorer can click on URLs that are constructed in several different ways to get to the root share in the example shown above.  Examining earlier posts in this bugzilla will demonstrate; most commonly, applications that use the technique will use URLs constructed with the prefix "file:" followed by five slashes and the servername.

If one attempts this in firefox, literally nothing happens.  No error, no diagnostic message, nothing.  Completely windows-user hostile.

If one attempts to click on a link to a specific share (usually constructed with a "file:" prefix, five slashes, a servername, a slash, and a share name) firefox will not present any message indicating that file URLs are a security hazard to the uninformed (they are) or that ff's treatment of file URLs is customizable by site and extremely wonderful (it is).  Instead, they get nothing.  Literally nothing happens.  This makes firefox appear to be broken when compared to IE, and there are numerous commercial applications that appear to be unuseable with firefox for this reason.

So, to sum up:

#1 Firefox is incapable of visiting root shares and thus cannot be used in place of IE in many windows environments.

#2 Firefox has better handling of file URL security hazards than any other browser, but because this is obscured from end-users, it is widely believed to be incapable of using local file links.

#3 Firefox behaves entirely correctly when visiting non-root shares if the file URL is typed directly into the location bar.

I believe this is because firefox does not pass UNCs to the MS-Windows operating system correctly, but I have not examined the code so this is little more than a guess.
Comment 34 User image DS 2008-12-16 11:01:39 PST
(In reply to comment #33)

I concur.  When will this be addressed?
Comment 35 User image mohamad 2009-06-07 15:53:36 PDT
Created attachment 382064 [details]

Note You need to log in before you can comment on or make changes to this bug.