Implementing ShareFile as cloud storage for a Windows Server 2008 R2

  • 1
  • Question
  • Updated 1 year ago
Hi all,

I had a question from a colleague who currently uses ShareFile for distribution of their work product, and a question came up about using ShareFile for backups of their local files.

They're currently running a Windows Server 2008 R2 that hosts files over the network for their individual workstations. The files are relatively small, and the total amount of files for the office they'd like backed up is about 700gb.

What they'd like to potentially use ShareFile for is having a sort of cloud backup for some of their shared files. In a perfect world what they'd like to do is have it where, when files are added or changed, a cloud copy can be uploaded to ShareFile as a sort of backup.

My thought was that something like that could be done using ShareFile Sync on Windows for individual workstations, but could something be applied to that Windows Server environment to achieve the same results? I wasn't as familiar with the options on their server, so I'm hoping someone can point me in the right direction in terms of recommending a solution.

Photo of Derek Letellier

Derek Letellier

  • 2 Posts
  • 0 Reply Likes

Posted 1 year ago

  • 1
Photo of Joseph Carpenter

Joseph Carpenter

  • 17 Posts
  • 4 Reply Likes
This may be more than you wanted to know, but this is my experience...

These cloud sync solutions can be used to create a hybrid "cloud/local" networking solution for SMBs to access local files, and also make the files available to cloud apps, mobile users, work from home, etc. Each sync product has its own unique challenges. e.g. DropBox, GDrive, ShareFile, Amazon, Azure, OneDrive, iCloud, Box, SpiderOak, JungleDisk, etc.  You can also "roll your own" using cloud accessible network attachable storage solutions like the ones from QNAP, Buffalo, Synology, etc. The market is saturated with solutions, and each solution has a myriad of custom implementations cooked up by admins just like us. 

It is worth nothing that creating a hybrid network with the dual purpose of providing local area network access to files that are also syncing to the cloud is NOT a true backup solution. If anything, the data is more vulnerable to network interruption, so creating a third tier backup solution to offline media is even more important. There are too many solutions for local sync, disk cloning and online backup to list them here. Just pick one that works for your situation and do not skip that extra backup.

For the record, we moved off of "DropBox for Teams" mainly because of rapid cost increases, but also because the features in ShareFile were more flexible. Each solution has its pros and cons.


ShareFile Sync for Windows works fine on Windows Server 2012 with the following caveats.

The implementation I have in place comes from ShareFile Support, but is not a standard installation configuration. It uses symbolic links, and solves several issues related to administering a Windows LAN. I will discuss those issues and how we solved them. I will also mention as many "gotchas" as I can recall along the way so you can hopefully avoid them.

ATTENTION: In late 2018, ShareFile announced that the "ShareFile Sync for Windows" app will eventually be replaced with "Citrix Files for Windows". I'm not saying it is enough to halt your project, but this is a period of uncertainty. Be aware of the change and stay in touch with ShareFile Support is my best advice.

Definitely review all of the information in the installation guide:

and the user guide:

Gotcha: Be aware that ShareFile Sync does not run as a service, so you must leave an account logged on with Admin rights.  I leave my ShareFile server locked, instead of logging out. This is identical to how the DropBox client works on a server.

Gotcha: Be aware that the long filename issue in ShareFile being limited to 180 characters in the path is no joke. Take the time to search those files on your network before rolling out ShareFile and clean them up in advance. Be aware that ShareFile Sync adds about 47 characters to the path of the target folder, and does NOT support creating network file shares to subfolders within that path. It can be done, but try to keep things simple to avoid issues down the road. Also, keep your naming conventions tight as well, if your users will comply.

I will next speak to how we have Sharefile Sync was originally installed and how it is working now. 


To introduce the present solution with symbolic links, I need to tell you how we got there.

Our drive S:\ is a QNAP Network Attached Storage device that is rated for 24/7 uptime. It is our file server connected to the Windows 2012 server via iSCSI protocols, which is how it appears as drive S:\. 

For about 18 months, we ran ShareFile Sync for Windows on Windows 2012 using the target drive S:\ in the ShareFile Sync configuration. This configuration was done with the advice and support of ShareFile Support, so I assumed it was supported. 

That configuration worked great, and only occasionally did I have to go make sure the client was running.  Usually after a certain vendor pushed updates and logged out my default server user. Notice what I said before about the user account running the ShareFile Sync client must remain logged on. 

Note: ShareFile officially reports they only support ShareFile Sync working with the default target location:

They say this, "The default sync location is C:\Users\username\ShareFile. This cannot be changed.
This tool can only sync to a fixed local drive. You will not be able to sync a network or removable drive."

Well actually... With the advice and help of ShareFile Support, I originally set the target location to Drive S:\ShareFile, and it worked well for a long time. About 18 months or so.

Then things changed...

Okay, so ShareFile was working great with a default installation pointed to drive S:\ShareFile ... Then earlier this year, ShareFile Sync stopped working with our drive S:\.

My best guess is an update to the ShareFile Sync app (about 3.21) began to enforce certain policies within the ShareFile ecosystem, and we were forced to make changes. The behavior seen was corruption of the ShareFile configuration file. This was seen as a failure to sync, and the configuration checkboxes were blank.

Gotcha: If you see this happen --> blank configuration checkboxes in the ShareFile Sync config -- DO NOT simply recheck those boxes. Doing so resulted in duplicate folders syncing down, and it was a mess. This is a known issue, and they do not seem to have a better procedure at the moment for recovering or repairing the configuration file. They do not have readily accessible log files to diagnose or troubleshot this issue, though there are temp log files if you are clever enough to copy them before they get deleted. Hopefully stability, recovery and logging capabilities will be improved in future versions of the Sync client. 

Note: Cleaning up a failed sync configuration can involve a complete uninstall and reinstall process, including resyncing all the data. And, ShareFile will bias towards downloading data from the cloud to local, not the other way around. So there is that bandwidth to think about as well. 

ShareFile Sync was also defaulting all users and groups, including "Domain Users" and "Administrator", to read/write only. Without Modify permissions, we could not use the data normally in the Windows environment. Symbolic links fixed that issue as well.  Therefore, even if I had a C:\ drive big enough, I would probably implement the symbolic links solution just to retain control of the folder permissions. 

That is what prompted me to share all of this with you. When ShareFile Sync started overwriting my users permissions, that was the issue that had to be resolved or it would have made ShareFile Sync unusable.

Moving the actual data storage outside the ShareFile default path, and linking to it with symbolic links, allows the administrator to assign folder permissions to users, groups, etc, and not worry that they will be overwritten. Let ShareFile Sync manage the connection to ShareFile, but not disturb the Windows permissions.


To fix that issue, we needed to install ShareFile Sync in its default locations AND I also needed to keep my existing data where it was. The C:\ drive was not large enough to hold that data store. 

So, ShareFile Support gave me a solution. We implemented symbolic links in the default location:
which directs each symlink to the corresponding folder in the larger storage on server drive S:\. This configuration was done with the help of ShareFile Support. 

Use of symbolic links is not recommended as a mainstream solution, but it did solve our issues. The files now sync much faster, and we don't have folder permission issues because the users access the files on folders that have their properties managed by Windows Server, not by ShareFile Sync. 

Note: I could write the full procedure here for how I created the symbolic links to each subfolder. However, I think it best if you contact ShareFile Support and do this with them. The reason is you should get the most current information available. Also, your needs may require a custom approach. 

The article is FAR from comprehensive, but the basic concepts for using symbolic links with ShareFile are outlined in this article:

The one thing I will say, is that I created ONE root folder in ShareFile to sync with. I could have called it anything, but I called it "SYNC". That is the only folder that is configured to sync with the ShareFile Sync client. The rest of the data is handled with subfolders. I did that so I could create the symlinks to correspond with the desired subfolders: Docs, Office, Users, etc. 

corresponds with SYNC in ShareFile dashboard.

I created SYNC in that online dashboard, and then configure ShareFile Sync to connect to it.

After that, each "sub-folder" in "C:\Users\Administrator\ShareFile\SYNC" is actually a symbolic link pointing to the corresponding folder with the same name in our Drive S:\. The icons that represent the sync status appear not only on the symlinks, but also on the actual folders. 

It is worth mentioning that these target locations could be linked anywhere in the windows network. It is best if the symlinks points to the same hard drive, but that was not possible for our situation. It is very important however that whatever target location you choose should be stable and ready for 24/7 availability. If the folder you are syncing to becomes unavailable, then you will get errors in ShareFile Sync. 


It is not as hard to implement as it is to write it up, but it does require an good attention to detail. It is not a configuration I would recommend for a new administrator. You have to document everything you do, and be very sure of your steps, because you cannot "see" what the symlink is doing. You have to "know." 

Best Practice 101 - Take your time and back up your data before you set this up. Just in case.  Then test your solution on non volatile data until you know you have it working correctly.

Once configured, ShareFile Sync for Windows on a server works great so long as all the variables stay consistent. We had that Sync client app update, and then we had to make changes to adapt. This is the nature of IT. The same thing could happen with a Windows Update, or a future update to ShareFile, or if some other component changes in your server. 

You may be getting on first name basis with the fine fellows at ShareFile support. We all learn from each other with every go around. They know their product, and we know our network. Making a better custom solution requires a team effort. 

So, the bottom line is ShareFile Sync definitely works on Windows Server 2012, and you should be able to get it to work similarly on Windows Server 2008. But that is a different OS, so be prepared to handle whatever comes up in your particular situation.

Photo of Derek Letellier

Derek Letellier

  • 2 Posts
  • 0 Reply Likes
Thanks so much for the detailed response! It helps a lot.

The changes to Sync are making me very nervous. As of right now Citrix Files does not have the ability to accomplish what we're doing in my company along with what my colleague wants to do in this situation listed above. I also have a lot more failures uploading/downloading with that program than any other ShareFile app. That being said, I think you've helped point us in the right direction.

One thing I suggested to them along with reading this guide is to look at the Data Migration Tool, which can help them at least get a start on their backup solution. Hopefully that can at least get them up and running.

Thanks again!
Photo of Joseph Carpenter

Joseph Carpenter

  • 17 Posts
  • 4 Reply Likes
When we implemented SF initially, we used the Migration tools to get all the data upladed into SF. It went basically one logical chunk at a time until everthing was in SF. Uploading with the Migration tool is much faster than trting to do same with SF Sync.

After that, it helps to realize that with SF, as with any cloud storage "sync" solution, the cloud version becomes the center of your data world. All other PCs, Servers, Mobile Devices, etc become endpoints.