62851 - (samba) file URL (and UNC path) fails to display share level

Status: RESOLVED WONTFIX

(Core :: Networking: File, enhancement, P3)

Description

[Prisacari Sergey]

\\natalie - doesn't work
\\natalie\incoming - work
NetBIOS network

Comment 1

[Keyser Sose]

Reporter are these local files or remote files? What build are you using? What platform are the files being hosted on etc?

Comment 2

[Prisacari Sergey]

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

[Eric Hodel]

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.

Confirming

Comment 4

[benc]

Open Networking bugs, qa=tever -> qa to me.

Comment 5

[benc]

-> file.
Similar to several other bugs.

Comment 6

[benc]

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

[Prisacari Sergey]

I entered this lopcation bar
"\\server\incoming" and "file://///server/incoming" works fine,
but both "file://///server" and "\\server" don't work 

Comment 8

[benc]

Okay.

This needs an additional round of definition.

Comment 9

[benc]

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

[benc]

+testcase

Comment 11

[benc]

UPDATE:
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

[Cormac F]

*** Bug 107540 has been marked as a duplicate of this bug. ***

Comment 13

[Ben Hutchings]

"\\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

[Jimmy Sieben]

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

file://server/share

When I click on one of these links, nothing happens. It works in IE.

Comment 15

[benc]

Please look at bug 122022.

Comment 16

[Doug Turner (:dougt)]

moving neeti's futured bugs for triaging.

Comment 17

[benc]

-> default owner

Comment 18

[Andrew Hagen]

This would be an enhancement, not a bug. Like comment 3, I recommend wontfix.

Comment 19

[benc]

RESOLVED/WONTFIX:
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.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnucmg/html/ucmgch06.asp

Would someone VERIFY/WTF if they agree?

Comment 20

[Andrew Hagen]

I agree with comment 3 and with Ben. Resolving as wontfix. 

Comment 21

[benc]

VERIFIED

Comment 22

[Prisacari Sergey]

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

[Andrew Hagen]

I found an IETF draft document that suggests:

//servername/

and

smb://servername/sharename

That draft is at:

http://www.globecom.net/ietf/draft/draft-crhertel-smb-url-02.html

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

[benc]

*** Bug 229436 has been marked as a duplicate of this bug. ***

Comment 25

[benc]

REOPEN: 

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:
file://///Home-users-comp/benc/

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

[Brian 'netdragon' Bober]

*** Bug 73003 has been marked as a duplicate of this bug. ***

Comment 27

[Brian 'netdragon' Bober]

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
http://phynd.chewplastic.com/ on Linux.

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

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

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
file://////////////////////////////////usr

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

[Brian 'netdragon' Bober]

*** Bug 236059 has been marked as a duplicate of this bug. ***

Comment 29

[Brian 'netdragon' Bober]

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
http://www.independentcommerce.com/icDirectory/keyword.asp?keyword=netserv
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

[benc]

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

[Pam Greene]

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

[Doug Turner (:dougt)]

mass reassigning to nobody.

Comment 33

[Medievalist]

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:

//servername
      /share1
      /share2
          /folder2.1
          /folder2.2
      /share3
          /folder3.1
               /folder3.1.1

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

[DS]

(In reply to comment #33)

I concur.  When will this be addressed?

Comment 35

[mohamad]

Attachment: ​