You would typically use Samba, but the specifics could depend on how you are authenticating users, whether the network shares are open without that authentication or not, and whether you are just trying to open up one or two shares, or if you want users to be able to add their own. I'm sure there are other important questions as well! In general, though, you would be handling the issue at the operating system level, not specifically within RStudio.
I work in a hybrid Linux (for RSP)/Windows (for everything else) environment, and the combination of the two OSs has been an interesting journey. I would urge you to move everything onto Linux if it's at all feasible.
Some issues we've had along the way
authentication across Linux/unix is hard, so for a short while users had to retype passwords and re-login a lot
at one point users had different read/write access on our windows servers from RSP, than from their sessions on windows which was confusing
when users reset their passwords on windows, sometimes that reset didn't propagate onto the Linux side immediately, again causing confusion
similar to passwords resetting, when folder-level access was changed on windows, it didn't always show up immediately on Linux and didn't throw errors that pointed to the real issue, so was hard to debug
apologies for not having solutions, i'm mostly just a user that has witnessed (caused) some of the problems.
Our intention is to host RStudio Server Pro on a Red Hat Enterprise Linux 7.4 server. But we have staff members wanting to be able to access multiple Windows network shares from within the browser based RStudio IDE.
Our client machines are Windows 8.1 Enterprise with LDAP authentication via Active Directory.
Similar to @Tanner's experience, I have lived in a Windows/Linux shop before (most desktops Windows based, all servers linux-based). We had some killer DevOps guys, but they went through a lot of headaches with Samba. They ended up settling on Isilon (I believe that's the right link), which had its own share of learning pains.
The pain Tanner mentioned is similar to what we experienced on both Samba and Isilon. The final state we got to, though, was really nice.
Windows users mapped to Linux users, so the file system always saw you as the same userid (file ownership was always by linux-cole, and never my windows counterpart)
Password resetting was seamless
Could edit files interactively from either system
I think Isilon is definitely geared towards scaling hardware in a virtual environment, but I would expect there are other solutions out there. I second the recommendation to move as much as possible to Linux, and use Mac Desktops as a fall-back before landing in Windows land. But then again, I am quite biased on that front