The default bug view has changed. See this FAQ.
Bug 62851 (samba)

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

RESOLVED WONTFIX

Status

()

Core
Networking: File
P3
enhancement
RESOLVED WONTFIX
17 years ago
a year ago

People

(Reporter: Prisacari Sergey, Unassigned)

Tracking

({arch, testcase})

Trunk
Future
x86
All
arch, testcase
Points:
---
Bug Flags:
wanted1.9.1 ?

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 obsolete attachment)

(Reporter)

Description

17 years ago
\\natalie - doesn't work
\\natalie\incoming - work
NetBIOS network

Comment 1

17 years ago
Reporter are these local files or remote files? What build are you using? What platform are the files being hosted on etc?
Summary: mozilla doesn't show list of shared folders via file protocol, but show shared folders content → NetBIOS files showing but folders not
(Reporter)

Comment 2

17 years ago
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

16 years ago
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: NetBIOS files showing but folders not → List of shares on an NT server not displayed

Updated

16 years ago
Summary: List of shares on an NT server not displayed → [RFE]List of shares on an NT server not displayed

Updated

16 years ago
Target Milestone: --- → Future

Comment 4

16 years ago
Open Networking bugs, qa=tever -> qa to me.
QA Contact: tever → benc

Comment 5

16 years ago
-> file.
Similar to several other bugs.
Component: Networking → Networking: File
Whiteboard: dupe me?

Comment 6

16 years ago
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. 
(Reporter)

Comment 7

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

Comment 8

16 years ago
Okay.

This needs an additional round of definition.

Comment 9

16 years ago
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?
Summary: [RFE]List of shares on an NT server not displayed → file URL (and UNC path) fails to top level of shared drive
Whiteboard: dupe me?

Comment 10

16 years ago
+testcase
Keywords: testcase

Comment 11

16 years ago
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.
Keywords: arch

Comment 12

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

Comment 13

15 years ago
"\\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

15 years ago
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

15 years ago
Please look at bug 122022.

Comment 16

15 years ago
moving neeti's futured bugs for triaging.
Assignee: neeti → new-network-bugs

Comment 17

15 years ago
-> default owner
Assignee: new-network-bugs → dougt

Comment 18

14 years ago
This would be an enhancement, not a bug. Like comment 3, I recommend wontfix.
Severity: normal → enhancement

Comment 19

14 years ago
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

14 years ago
I agree with comment 3 and with Ben. Resolving as wontfix. 
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → WONTFIX

Comment 21

14 years ago
VERIFIED
Status: RESOLVED → VERIFIED
(Reporter)

Comment 22

14 years ago
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

14 years ago
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

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

Comment 25

13 years ago
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.
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
Summary: file URL (and UNC path) fails to top level of shared drive → file URL (and UNC path) fails to display share level
*** Bug 73003 has been marked as a duplicate of this bug. ***
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.
OS: Windows 2000 → All
*** Bug 236059 has been marked as a duplicate of this bug. ***
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:///
Alias: samba

Comment 30

13 years ago
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.

Updated

13 years ago
Blocks: 73003

Comment 31

11 years ago
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

10 years ago
mass reassigning to nobody.
Assignee: dougt → nobody
Status: REOPENED → NEW

Comment 33

9 years ago
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.

Updated

9 years ago
Flags: wanted1.9.1?

Comment 34

8 years ago
(In reply to comment #33)

I concur.  When will this be addressed?

Comment 35

8 years ago
Created attachment 382064 [details]
Attachment #382064 - Flags: review+

Updated

3 years ago
Attachment #382064 - Attachment description: love → ​
Attachment #382064 - Attachment is obsolete: true
Attachment #382064 - Flags: review+
Status: NEW → RESOLVED
Last Resolved: 14 years agoa year ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.