ShareFile client does not sync with file permission attributes inherited from the parent folder in which it's syncing to.

  • 1
  • Problem
  • Updated 23 hours ago
I'm having difficulty with the ShareFile windows sync client once things have synced to my server. The client runs on my server via an administrator account, and it syncs files to the local HDD on the server. This sync folder is shared to other users on the network as a mapped drive. When new items are added via the website or another member in my organization shares something with me, the files DO sync to that local folder on the server like they are supposed to and are able to be seen by other users on the network that have access to that shared folder on the server. The problem is that none of the accounts that have permissions to list the folder contents seem to have the permission to read any of the files (can't actually open them). The permissions don't get set up on these newly added files as one would expect. Meaning, they are not created on the server during a sync with inherited permissions from the parent object. The parent object/folder is setup to provide inheritable permissions to child objects, and it does so correctly when I just drag and drop a file from on the server into that folder.

The "fix" that I have been using temporarily is to right-click on the parent folder, click the security tab, click advanced, click the checkbox for "Replace all child object permission entries with inheritable permission entries from this object", and finally click okay. I have to do this multiple times per day... If I don't, other users that don't have an admin account cannot access the files.

Any ideas/recommendations/help would be appreciated. Thanks!
Photo of Nick Davis

Nick Davis

  • 7 Posts
  • 0 Reply Likes
  • frustrated

Posted 3 years ago

  • 1
Photo of Ashlee Burch

Ashlee Burch

  • 676 Posts
  • 30 Reply Likes
Hi Nick,
Can you confirm which Sync tool you are using? I have my engineers looking into this and they want to ensure that the program and also whether or not this is a permissions issue with the server.
Photo of Nick Davis

Nick Davis

  • 7 Posts
  • 0 Reply Likes
I have replied to you numerous times. Do you have no care in the world for this issue? Some kind of update would be appreciated. It has been 3+ weeks since you asked this question which came 6 days after my original post. Are you still working with ShareFile? Were you eaten by a bear? What is the problem with your customer support follow-through? It's beyond frustrating. This is a serious issue, and it warrants an expeditious response.

If you need more information than that which has already been provided, I fully expect you should have asked for that by now. Please, have a since of urgency and realize that this is an ongoing problem that is impacting our business and our desire to continue using ShareFile.
Photo of Nick Davis

Nick Davis

  • 7 Posts
  • 0 Reply Likes
Hi Ashlee,

I don't want to come off as rude, but I feel fairly confident that there's only one "ShareFile windows sync client", though it is called "Sync for Windows". If there are more options that I just don't see available for download that meet the functionality of the description and have a name that's almost as similar, then I apologize for not being more clear, but otherwise, "Seriously? You need clarification on that?"

(1) Client is running on a Windows Server 2012 system
QUESTION: Can this tool be run as a Windows service? Would that provide me with the functionality that I desire since the client wouldn't be tied to any one user? What would be the best way to set that up so that the permissions aren't an issue?

(2) When I right-click the sync tool icon in the system tray, click "preferences", and then click the "about" tab, it says ShareFile Sync v.3.4.120.3. When I posted my comment, I was fairly confident that I was using the latest sync tool. However, today I went to the download page and found out that there is a more current version available. I won't know until tomorrow whether or not the new version fixes the problem. If it does, I'll post an update.

(3) The issue is not present when I copy files into the local folder when I'm logged into the server. The issue is not present when I copy files into the local [network] folder when I'm at my desktop in my office.

**The ONLY time the issue is present is when Sync for Windows automatically syncs (downloads) new files that have been uploaded to ShareFile via the web interface or after being shared by another ShareFile user.**

I feel very confident that the permissions are setup correctly since everything functions as one would expect in the local environment. Please help me with this ASAP.

Thank you,
Nick
Photo of Nick Davis

Nick Davis

  • 7 Posts
  • 0 Reply Likes
Hi Ashlee,

The new version of the Sync for Windows (v.3.4.124.0) did not fix the problem. The program currently runs on the server only after I've logged into it once and locked it. That's why I've inquired as to how to make best set it up to run as a windows service as well.

The permissions are available to the following users/groups when Sync downloads the files:

SYSTEM
Administrators
Nick (my local account)

The permissions that are available when a file is copied into the local folder on the server:

SYSTEM
Administrators
Nick (my local account)
Technicians
Users

This is very weird. I don't have a clue as to why files would be created on my local machine with a different permissions schema than the one that windows is using for the folder that files are being created in when that folder is set to have inheritable permissions to all of it's descendants and functions properly when utilized on the local environment by users... :-/

Thanks,
Nick
Photo of Nick Davis

Nick Davis

  • 7 Posts
  • 0 Reply Likes
Please, answer my question!! I've given you all the information you need. Did you go on a 2 week holiday or what? I responded to your answer within 2 hours of you posting it. Where is your sense of urgency?!?!?!
Photo of Louis Ellis

Louis Ellis

  • 2 Posts
  • 1 Reply Like
So firstly this problem is apparently "by design"; the recommended solution is to use the UMT tool to sync your AD users and Groups with ShareFile and this apparently will mean newly synced files have the correct permissions.

I didn't want to do this, so I found that when you sync a file, the sharefile client first downloads it to the TEMP folder under the users local %appdata% - i.e. the Administrator account - and then moves it to the final location with the correct file name.

The file inherits its NTFS permissions from this folder. Adding the required security groups to the temp folder then causes them to be inherited in the file created by ShareFile and of course retained when it is moved to the final location.

Hope this helps
(Edited)
Photo of adam

adam

  • 3 Posts
  • 0 Reply Likes
Mike,  I am having the same issue.  Can you provide a bit more detailed information about how you addressed this problem?  Thanks.
Photo of Mike Michelakis

Mike Michelakis

  • 3 Posts
  • 0 Reply Likes
Hey Adam, whichever account has the sync program running (usually the admin account) you would go to C:\Users\<account>\  Then unhide the hidden folders, right-click the 'AppData' folder, go to properties and then change the security on this folder to include whatever you need the final location to have and set it to replace all child objects with inheritance from this object.  in my case i added a security group for one of the teams here.  Then when the file is downloaded to the temp folder under AppData during the sync process, it will get the additional permissions, and then they will be retained in the final location.  Hope that helps
Photo of adam

adam

  • 3 Posts
  • 0 Reply Likes
Thanks Mike.  I appreciate your help.  I followed your advice but still have half a dozen files that won't sync.  There doesn't seem to be any pattern.  They are all different file formats (pdf, ppt, xlsx, docx), some are password protected some are not.  I am at a loss.
Photo of Mike Michelakis

Mike Michelakis

  • 3 Posts
  • 0 Reply Likes
they don't sync?  That's a different issue then, my issue was with file permissions.  That being said, i did have an issue with syncing at one point and it was due to, of all things, share quotas.  i don't remember setting one up but it was there.  once i removed it the issue went away.  Found the windows event viewer helpful with that one.  Good luck
Photo of adam

adam

  • 3 Posts
  • 0 Reply Likes
Yea.  I get a file sync error (red triangle) and it say "there was a problem uploading this file due to a permission error.  contact the folder owner for appropriate permissions".  However the files that don't sync are all located in different folders and there are other files within those folders that do sync.  Thanks anyway.
Photo of Joseph Carpenter

Joseph Carpenter

  • 6 Posts
  • 1 Reply Like
I am also looking at the solution provided in this thread regarding how file permission are affected when they flow through a TEMP folder during the sync operation.


Looking for the exact path to modify local permissions to solve this "temp transfer permission" issue. All hidden files are revealed.

I do not find a folder for C:\Users\Administrator\AppData\Roaming\TEMP

I do not find a folder for C:\Users\Administrator\AppData\Local\TEMP


I DO find this: C:\Users\Administrator\AppData\Roaming\ShareFile

There are no TEMP folder in there now, and no files that look like they are in transit. Are these locations created and then destroyed when the ShareFile Sync Client syncs?


My larger issue can be described as follows:

I am seeing ShareFile overwrite permissions that I have assigned. Key basic permissions needed are as follows:
SYSTEM = Full Control
Administrator = Full Control
Domain_Users = Modify

Those remain stable for some period of time, then are occasionally overwritten by ShareFile within the ShareFile root folder used by the ShareFile Sync Client.

The entries for Everyone, Administrator, Administrators, Domain_Users, and Users are all overwritten with: Read/Execute, and the Write permission gets removed. Only SYSTEM retains its Full Control permission.

Perhaps SYSTEM is what ShareFile is using getting things done. It seems so.

Functionally, this means Domain_Users, and the Admin, in particular, cannot Move or Delete any files. And therefore these users cannot "use" the files they need to manipulate to do their job functions.

I periodically reassert the correct perms, and let them propagate, but this issue keeps coming back. Not just on newly transferred files, but existing folders and file permission are overwritten as well.

This is happening in subfolders under the ShareFile parent folder, so I am pretty sure it is ShareFile doing this with some kind of scripted behavior. Not sure yet if it is by design, or a glitch, or a configuration error. 


Not getting any answers when I call support about this. They seem pretty clueless about the actual underpinning about how all this works and I can tell most are just reading from the KB articles. No joy so far on getting tickets promoted up the chain to a developer or other knowledgeable person. 

I may be missing something, but also hoping the community knows something... because this issue cannot continue unresolved. Users must be able to actually use the data. Or we will have to look for an alternative to ShareFile.


Photo of Mike Michelakis

Mike Michelakis

  • 4 Posts
  • 0 Reply Likes
Hey Joseph, I found i needed to change the permissions directly on the root of the appdata folder (and propogate down), changing it on the subfolders didn't work.