Sharepoint 2013 – Open file share search results in Non-IE Browsers & IPAD


In SharePoint 2013, if non-IE browsers are used to open the file share results (eg: file://sp2012/Share/test.docx) it may not work as expected. Looks like this a known behavior to avoid security problems.


1) Deploy a HTTP handler at _layouts to download the data from the file share

2) Modify all the file-share HREF’s in the display template to call the handler

1) Deploy a HTTP -handler at _layouts to download the data from the file share:

Create a HTTP handler download.ashx and drop it at _Layouts folder

<%@ WebHandler Language="C#" Class="download" %>

using System;
using System.Web;
using System.IO;

public class download : IHttpHandler {

 public void ProcessRequest (HttpContext context) {
 string file = context.Request.QueryString["file"];
 // if (!string.IsNullOrEmpty(file) && File.Exists(context.Server.MapPath(file)))
 if (!string.IsNullOrEmpty(file) )
 Uri uri = new Uri(file);
 context.Response.ContentType = "application/octet-stream";
 //Set the ContentType to "application/octet-stream" which cover any type of file
 context.Response.AddHeader("content-disposition", "attachment;filename=" + Path.GetFileName(uri.LocalPath));
 catch (Exception ex)
 context.Response.ContentType = "text/plain";
 context.Response.ContentType = "text/plain";
 context.Response.Write("File cannot be found!");

 public bool IsReusable {
 get {
 return false;


This handler can be tested by using simple HTML  like this

<!DOCTYPE html>
<html xmlns="">
 <a href="Download.ashx?file=file://sp2012/Share/AddClickToDiv.docx">Download</a>

HTTPHandler accepts any query string passed with “file” parameter (Download.ashx?file=”file location”) and downloads the file.

2) Modify all the file-share HREF’s in the display template to call the handler

~sitecollection/_catalogs/masterpage/Display Templates/Search/Control_SearchResults.html is the display template used to render the search results.

Add new cutsom javascript file “replacehref.js” in the beginning of the body and call the function “setFileshareHandlerHrefs” using script on demand JS libraries.

 $includeLanguageScript(this.url, "~sitecollection/_catalogs/masterpage/Display Templates/Search/replacehref.js");
 <div id="Control_SearchResults" >

 AddPostRenderCallback(ctx, function()
SP.SOD.executeOrDelayUntilScriptLoaded(setFileshareHandlerHrefs, "sp.js");

Now in the replacehref.js select all the HREF elements from the display template (var selectors = [‘.ms-srch-result a’]) and replace all the URL’s with handler and file parameter

/// <reference path="" />

function setFileshareHandlerHrefs() {
var fileshareHandler = "/_layouts/15/download.ashx?file=";
var filePrefix = "file://";
var selectors = ['.ms-srch-result a'];
$.each(selectors, function (i, selector) {
$(selector).each(function (e) {
var hrf = $(this).attr('href');
if (hrf.indexOf(filePrefix) > -1 && $(this).attr('FileHandlerSet') == null) {
hrf = _spPageContextInfo.siteAbsoluteUrl + fileshareHandler + hrf;
$(this).attr('FileHandlerSet', true);
$(this).attr('href', hrf);

Now when the file share link in the search result page is clicked, it calls the handler and file will be downloaded.
This is tested in IPAD and other major browsers.


This work around may not work with the kerberos enabled sites due to “double hop” issue. Since the /_layouts folder is registered under apppool account, impersonating the http handler with context user on kerberos enabled site causes conflicts in accessing file share. To resolve this issue

  1. Add a new folder “handler” on C:\inetpub and copy the Download.ashx, test.html and web.config files.
  2. Right click portal site from IIS -> Add Application and set physical path to C:\Inetpub\handler
  3. Select portal app pool as application app pool
  4. Now set “Connect As” to your file share crawl account
  5. Reset IIS
  6. Change the following line from var fileshareHandler = “/_layouts/15/download.ashx?file=”; to var fileshareHandler = “/handler/download.ashx?file=”;

This will resolve the double-hop issue.