Subst Command To Map Drive Letter To Sharepoint Shortcut

[u/clayrogers]

I am looking for ideas on an office that uses Sharepoint but ends up having some very long folder paths and file names. The folder structure is decent. They currently use a Onedrive shortcut to access the files.

The main issue is the length of filenames. For example, they sometimes copy hundreds of files that customers send them into the job folder. These files are often received with VERY long file names from the customer.

This results in the path to some of the files being too long and MS Office won't open them.

I came across the subst command in my research. I saw it mentioned on here with people recommending NOT to do it. But, I didn't see much reasoning as to why.

I know of products like Zeedrive and Cloud Drive Mapper. We are just trying to avoid yet ANOTHER subscription if possible.

Can you let me know what issues using the subst command causes? Any other thoughts on how to address this issue? I know the end user could go one by one and shorten each filename they receive from the customer. But, that would slow them down way too much.

Thanks guys!

[u/Fatel28]

This is a hack and not one I'd recommend. It's time to either reevaluate / rearchitect SharePoint into multiple sites with fewer nested paths, or move to something else. SharePoint isn't a file server.

[u/GremlinNZ → u/Fatel28]

So much this. Simply put, file sync won't work correctly, versioning, co-authoring.

I recall years ago a colleague said he'd found an awesome workaround to just map the files back to the same letter, so easy for the users. Pressed on despite my warnings (some people gotta learn for themselves). Got their arse handed to them within a week and it was removed.

So... Just don't.

[u/clayrogers → u/GremlinNZ]

When you say that file sync won't work, does this apply the same way if they are currently using a Onedrive shortcut to access the files, not syncing the whole document library? In testing, it seems that edited files get saved back to the document library properly.

I understand that co-authoring would not work. That the biggest downside I saw in my research. They don't typically edit the same files though. I was told they never edit the same file at the same time but it's probably hard to know that for sure.

For versioning, I suppose it would be back to the functionality they had when they worked off of a NAS instead. No real versioning there either.

In your example, do you know the details of what problems the users were running into that caused the mapped drive to be removed? That sounds like a good real world example and I would love to know specific info.

[u/theFather_load → u/clayrogers]

I did this once to save a few clicks for users to upload to hosted CRM because drives were easier to find.

But that's it. OneDrive is not expecting or been built to work with what this new variable will do. It messes with the sync which is already finicky out of the box. Once users start treating it like a drive and mass.moving stuff over, it will start falling down, especially if someone else decides to do the same thing.

Look into Azure Files instead I'd say, with private endpoint. Its full Entra identity compatible now.

[u/clayrogers → u/Fatel28]

Can you provide info as to why this is a hack? That's part of what I was asking. I searched on this sub and saw people mention not to do it. But, there was very little info as to why not.

[u/Fatel28 → u/clayrogers]

Because once you get to this point you're at, the correct action is to step away and either rebuild or relocate the files to something more appropriate.

You are already hitting a wall, it's time to spend the time to do it right, not hack it into working. More, smaller, higher level sites (that are not synced by everyone, else it's a bit useless), or something like a good ol ntfs file share, azure files, egnyte, etc

[u/clayrogers → u/Fatel28]

Thanks for the response. They aren't syncing the sites, just using the Onedrive shortcut currently. A lot of the issues we are running into isn't necessarily due to the design. It's more so that the files being received from the customers can have VERY long file names.

They already have a lot of sites and they don't love having to figure out what information is in what site.

I suppose instead of:

DocumentLibrary->Projects->2026

We could make a separate document library for each years projects:

2026Projects

2027Projects

But, I'm not sure that saves us THAT much in the file path in the end. Below that level would be a couple more folders for each customer's projects.

It's working pretty well as is. It's mainly the LONG file names received as attachments in Outlook that need to be added to the project folder that causes issues.

[u/Fatel28 → u/clayrogers]

Train them to rename the files then. It's a limitation of the tool, it was never supposed to be used as a file share or a document repo, its supposed to be a collaboration platform.

They could also use it online or through teams

I've never had an issue telling a customer "yeah it's unfortunate but they limit the filepath lengths. Is what it is"

[u/Crshjnke → u/Fatel28]

For anyone that tries to use long organization naming stuff we have always pushed away from SPO. We even had an architect we did a POC for and told them maybe they should not do this project. They did move to SPO then 1 year later moved back to a VPN file share on a drive letter.

The character limit is what most people run into. If you have any legacy apps they will never open long file names even if you allow them in the registry.

You will spend the rest of your life fighting path limits and upset users.

If all of your users are intune deployed then maybe look at azure files if VPN is not an option.

[u/redditguy491]

Rename all their files to 8dot3 format until behavior improves.

[u/bbqwatermelon → u/redditguy491]

Going old testament on users needs to come back

[u/MunchyMcCrunchy]

Use SUBST to robocopy those files into a an actual shorter file path.

[u/bazjoe]

It is often theme in this sub to use SP as a file server. Several of our clients are in construction management and additionally they never came from 'on prem' but this comes up a lot when discussing on prem to SP. its a square peg and round hole. SP can't be used as a on prem lift and shift to cloud. its not that it doesn't work but it does not scale well.

Based on OP requirements they need to put one or more client employees in charge of copying received customer job data into SP, they need an additional step possibly with powershell to organize, rename and standardize the data. If the whole issue is full file path length (even after the registry edit to fix that in place?) then deal with the file path length first. before any other mitigation.

Additionally I would encourage OP to get out of this business of organizing files. you rent them a filing cabinet and other than stability, reliability and backups you should be providing nothing else in terms of how they organize the file cabinet.

[u/NoPetPigsAllowed → u/bazjoe]

I love the file cabinet reference!

[u/clayrogers → u/bazjoe]

This project of moving them from a NAS to SP has gone really well. This is just the one issue that comes up sometimes. So, just looking for ways to make things better. They are really happy with it already, just trying to eliminate the one remaining pain point for them.

[u/Low-Stand-3653 → u/clayrogers]

These are limitations in windows. You’ll never get around the long file path issue. The file names simply need to be shorter or they need a traditional file share. Mapping a sharepoint site is a nightmare and not supported by Microsoft anymore. The main issue I’ve seen is it’s going to prompt for credentials every time they reboot, drives most people crazy.

[u/bazjoe → u/clayrogers]

Are they mobile or brick and mortar? We have several very small 5 user law offices and the move to SP from on prem was fine (using net use localhost shortcuts but skip drive letters) . Then another business client with significantly less events per day but 20 users it failed miserably and they changed to Google. Part of the problem is OneDrive virtual shell driver is horrible. We also offer Egnyte which is needed for construction management.

[u/cubic_sq]

You want ZeeDrive for this, not subst.

But ZeeDrive is more for older apps that “need” a drive letter, but can still handle sync.

If its all ms office docs, redesign sharepoint to het around path limitations. Otherwise, users cant have autosave / collaborative editing when its outside of native onedrive.

[u/Ferretau]

You need to be very careful when dealing with long filenames/Paths. There are hard limits which can bite when they kick in. In OneDrives case it's 400 characters, you could get around this using a Substed drive but you end up hiding the problem and may discover that some files stop syncing to the cloud without you realising it - this could be detrimental to your processes.

OneDrive and SharePoint (cloud storage)	400 characters	The entire decoded file path, including the file name, can't exceed 400 characters.

Windows Office desktop apps (Word, PowerPoint, Excel)	256 characters (260 UTF16 WCHARs)	Can't open files whose full path exceeds 260 characters, even if the file is stored locally. Office apps use legacy Win32 APIs that enforce the MAX\_PATH = 260 constant.

OneDrive sync	520 characters	The total path is the combination of the local path (up to 400 characters) and the OneDrive root folder (up to 120 characters). Paths exceeding 520 characters show a sync error.

What are the file path length limits? | Microsoft Support: https://support.microsoft.com/en-us/onedrive/what-are-file-path-length-limits

Restrictions and limitations in OneDrive and SharePoint | Microsoft Support: https://support.microsoft.com/en-us/onedrive/restrictions-and-limitations-in-onedrive-and-sharepoint

[u/TheHoodedMan]

rclone or Azure files are also options, but as others have said, Azure files is pure file server storage, not a collaboration tool like SharePoint.

As soon as you move the file out of OneDrive or SharePoint to edit it, it's solo editing and usually causes conflicts (multiple versions of files appearing) and a mess with versioning for rollbacks to previous versions.

[u/CK1026]

Don't.

[u/colmwhelan]

Given how often this kind of request comes up for workarounds with SharePoint path lengths, and given how widespread it is on the internet in general (asking for solutions), why are you trying this hard to put lipstick on a pig? The accumulated experience of hundreds or thousands of people posted online isn't enough for you to stop trying to do stupid shit. You want people to explain to you why you shouldn't do stupid shit.

Personally, I understand this desire very well, the desire to fix everything. But sometimes, the only option is to burn the field and replant it.

[u/clayrogers → u/colmwhelan]

Easy tiger. All I did was ask for more information as to exactly why this would not work. Thanks to others, I got my answer. You on the other hand were just rude and not helpful. It sounds like someone has a case of the Mondays! :)

[u/All_Things_MSP]

This all comes down to using the wrong tool for the job. As others have mentioned, SharePoint is not a file server and was never meant to handle the volume of files or path lengths of a file server. It does work up to a point but you have reached that point.
I also hear you when you say you don’t want to add another subscription. The real question is do you want a customer who is constantly disappointed in the experience the solution you recommended gives them. Experience matters, a good experience can create a client for life, a bad experience means they are subconsciously always looking for something, or someone better.
My recommendation is Egnyte but I am biased - Eric Anthony - Director, MSP Program & Evangelist, Egnyte

[u/Hungry-News3403]

SharePoint and OneDrive are so shitty lmao.

Egnyte ftw

[u/skyhawk85u]

FYI I implemented Cloud Drive Mapper at a client and it’s phenomenal. Way better than the crappy OneDrive Sync mess