Actually, no. From RFC 1738, Section 3.10:

   A file URL takes the form:
   
       file://<host>/<path>
   
   where <host> is the fully qualified domain name of the system on
   which the <path> is accessible, and <path> is a hierarchical
   directory path of the form <directory>/<directory>/.../<name>.

And then in Section 5 (the BNF):

   ... elements may be preceded
   with <n>* to designate n or more repetitions of the following
   element; n defaults to 0.
   
   fileurl        = "file://" [ host | "localhost" ] "/" fpath
   
   fpath          = fsegment *[ "/" fsegment ]
   fsegment       = *[ uchar | "?" | ":" | "@" | "&" | "=" ]

So that first slash isn't part of the path, and the path starts with a directory name. The fact that the root directory in a UNIXy environment doesn't have a name (or has a zero-length name) is a source of much confusion. (Nobody would accept "file:////etc/passwd" as a URL, but that's how I read the spec.)

This is also why Firefox insists that there are five consecutive slashes when encoding a UNC string (a Windows/Samba share path, like "\\server\share\path\to\file.txt") into a URL (e.g.: "file://///server/share/path/to/file.txt")

And let us not even begin on the fact that file: URLs are specified in an "obsolete" spec, and explicitly allow characters in the path that are disallowed by RFC 3986. I'm working on fixing that [https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme] but it takes time.