SharePoint Open with Explorer Errors – The Parameter is incorrect

Thanks to Jeremy for this one

We ran into a problem recently where attempting to open a SharePoint folder with Explorer would cause the following error: <URL> is not accessible.  You might not have permission to use this network resource. Contact the administrator of this server to find out if you have access permissions.  The Parameter is incorrect.

image

Permissions were being inherited from its parent all the way to the Home folder, and permissions on that folder were exactly the same as another folder within the same parent folder (and the other folders in the parent folder would not give an error when opening with Explorer). I created a copy of that folder and copied the files over one at a time (thankfully there were only a few files in that folder), and tested opening with Explorer with each file I added. Every time it opened correctly until I got to this guy:

image

As soon as I removed it from that folder – presto! Problem solved! Armed with the how but not the why I took the battle to the Googles… and I came across a forum post that mentioned illegal characters in the file name, so I started to suspect that this is where the problem was. My first thought was that it was the plus sign, but that wasn’t it, and it wasn’t file length either (260 characters allowed in the complete URL for the file or folder – just in case you were wondering). After trying variations of file length and removing characters to no avail, I copied the URL to the file and pasted it into Notepad. Turns out that one of the spaces in the filename had an ascii 255 character that looked like a space, but wasn’t.

image

I renamed the file and removed the offending space and put it back in again, and now it was properly rendered in the URL as %20,

image

and now Open in Explorer works as it should in that folder. Success!!

15 responses to “SharePoint Open with Explorer Errors – The Parameter is incorrect

  1. I came across the same kind of problem, and it was also caused by an “odd” character in PDF file name, I think it was &

  2. Any easy way to find the url? i.e. list coloum. I’m getting this error and have a couple of 100 documents in my list.

  3. Export SP list to excel.
    Add the following macro code

    Sub ExtractHL_AdjacentCell()
    Dim HL As Hyperlink
    For Each HL In ActiveSheet.Hyperlinks
    HL.Range.Offset(0, 1).Value = HL.Address
    Next
    End Sub

    Now you’ll be able to see your urls and also coverted ascii characters. Delete and test documents 1 by 1. Found mine on the first go – phew.

  4. Wow, thanks a lot i had the exact same issue and wasted a lot of time to solve it.
    Thanks Sean for sharing

  5. This helpet me a lot. With the macro I found the illigal char %C2%A0 in one of the filenames. The folder has over 1000 files, so it would have been a real pain to find without this. Thanks!

  6. I was experiencing the same error and was able to find a file inside the folder with the same invalid ghost character. Thank you for this post – it saved me a lot of trouble!

  7. Brilliant ! Thank you. This fixed my error very quickly 15000+ files to go through – I would never have found it without this. Once it was in excel I filtered on all files containing % and had only a pageful to consider – 2 had the invalid space.

  8. Thanks for your post. I have a question, When we are uploading the files, if the file name contains some spaces, then spaces should render in the URL as %20. Again doing rename / put space back again then space rendering as %20.
    But why it is not happening for some times. Any ideas on this.

  9. Thanks so much!!! This solved what seemed to be a complex issue but gave a real easy solution!!! Cant thank you enough

  10. You saved my day! Googled a lot till i found your post. Filtered for “%C2%A0” in Excel, found 1 document, and renamed it via SharePoint, et voila… webdav Access is working.

  11. Life saver!!! Thank you. Like another user above, my client had over 10000+ files but nested in many folders below. I was going to attempt file-by-file to understand the root cause and it was the top parent folder itself.

Comments are closed.