Create Folder Links for Sync for Windows

To create a symbolic link between your desired folder and your ShareFile account, you will need to use the Mklink command within Windows Command Prompt. To link your folder, run the Mklink command with the necessary folder information based on the template and example below.

Note: When designating a location in your ShareFile account, add a new folder to the ShareFile file path to correspond with the new linked folder. Ex: C:Users(Your Username)ShareFilePersonal FoldersMy Link Folder

Template:

  • Mklink /D <ShareFile Location> <SourceFolder>

Example mklink command:

  • Mklink /D “C:Users(Your Username)ShareFilePersonal FoldersMy Link Folder” “C:Users(Your Username)DesktopMy Link Folder”

Once run successfully, the folder will be created within your Sync location, and the linked folder will be synchronized with ShareFile anytime a new file is uploaded to or downloaded from that folder. The linked folder should show the green Sync overlays for individual files that are synced or syncing.

User-added image
User-added image

User-added image

Guidelines

  1. Windows NTFS file system should be used.
  2. Symbolic links to individual files are not supported
  3. Links work best within the same drive. Links to removable disks and network locations may be removed or disconnected, which can interfere with the link to Sync and cause various issues.
  4. A folder can only be linked in one place within Sync. For example, if the C:UsersUserADocuments is linked to ShareFilePersonal FoldersLink, it cannot also be linked to ShareFileShared FoldersLink.
  5. Renaming of the source folder will break the symbolic link. However, if the source folder is renamed back to its original name, the file may not be uploaded. Sync would require a restart in this case.
  6. You cannot create child links to the source folder you already created. For example, creating 2 links as follows will not work: C:usersuserADocuments and c:usersuserADocumentsFolderA

“Cannot Create a File when that file already exists”

  • This often occurs when the “ShareFile” filepath of your command is pointing to a folder that already exists in ShareFile. Add a folder to the file path, such as “….ShareFilePersonal FoldersLinked Locations

Related:

Configure Citrix Profile Management through WEM

Central Profile Management Store

1. Shared permissions

User-added image

2. Shared caching options

User-added image

3. NTFS permissions

User-added image

4. File and Storage services

User-added image

User-added image

Group Policy

Make sure the WEM clients (computers/servers or VDAs) are configured to receive the following GPO. ADMX and ADML files are downloaded with the same download package from Citrix Downloads WEM, they need to be copied to C:WindowsPolicyDefinitions or \<domain.here>sysvol<domain.here>PoliciesPolicyDefinitions

User-added image

WEM Client

Install latest WEM Agent from Citrix downloads website with the file named “Workspace-Environment-Management-v-4-XX-00Citrix Workspace Environment Management Agent v4.XX.00.00 Setup”

This agent will also install the following components

• Microsoft SQL CE 3.5 SP2 (x86 and x64)

• SyncFx 2.1 Synchronization

• SyncFx 2.1 ProviderServices

• SyncFx 2.1 DatabaseProviders

WEM Infrastructure Server

1. Make sure WEM clients are added into WEM console

User-added image

2. Apply UPM Settings

User-added image

User-added image

User-added image

3. Refresh client cache (a click to Refresh may be required)

User-added image

User-added image

User-added image

4. Test

Related:

Document not saved and Invalid Disk

I need a solution

I’m having two odd issues.  I have encrytion being done based on Active Directory Groups.  There is a single user in group one that has an issue where some office documents they cannot save, when they try they get “Document Not Saved”.  This is odd because it is only happening to one person in the group and this person can save some files in the encrypted network share but not others.

The second person is trying to rename a folder but gets “Invalid Disk”.  This folder they are trying to rename is at the top level of their encrypted share.  I had them go down one level and try to rename one of those folders and they could without issue.

Some troubleshooting steps I have taken are the following:

– I had both users attempt to complete their task in an unencrypted location.  I also had them try to compmlete their task with the same files/folders in a decrypted state and both situations worked.

– I have compared both users to other users in the group that are not having issues.  All PGP settings and NTFS settings are identical.

– I have removed PGP and its associated folders from the two user’s computers and completely re-installed.  This did not help.

Any thoughts?

0

Related:

ShareFile Search Fails

Metadata indexer will be updated in future release to ignore case of file extension.

Current workaround would be to re-upload files after updating file extension to lower case.

Command syntax example:

ren *.DOC *.doc

Same with any other relevant file types.

Limitations

Currently, files greater than 20 MB are not indexed for Full Text Search, and will not appear in search results.

This feature is not available for files stored in an on-prem StorageZone.

Related:

ccSvcHst.exe flooding security logs with failed write access

I need a solution

Only on my Domain Controller (Windows Server 2k8 R2) I am seeing my security logs flooded with Failed Audit Access events during every system scan. The process is ccSVCHst.exe (running as System) and it appears it is failing access on most everything under C:Windows*.

I have checked the specific file permissions on a few of the failed items and System only has Read & Execute. The failed audit flag is showing ccSvcHst.exe is being denied WRITE accesses to each file which is why the event is being logged. I wanted to see why ccSvcHst.exe virus scanner is needing WRITE permissions to these files and how to best fix this. I did not want to exclude C:Windows* from the daily scans as that would be a large chunk of critical files not getting scanned. I also did not want to grant WRITE access to System for all those files until I found out why it needed WRITE accesses. 

I have this same SEP scan running on my Windows 7 clients and it has none of these errors shown even though the NTFS file permissions are identical with only allowing System Read & Execute. 

0

Related:

Isilon OneFS: Traverse checking in OneFS and how to enforce it

Article Number: 503047 Article Version: 5 Article Type: How To



Isilon OneFS,Isilon OneFS 7.1,Isilon OneFS 7.2,Isilon OneFS 8.0,Isilon OneFS 8.1

By default, in OneFS, the following is true with respect to path traversal:

  • If an ACL exists on a directory, the traverse permission is granted (bypass traverse checking)
  • If no ACL exists (synthetic/POSIX), an explicit execute permission is required

A Microsoft Windows environment has a GPO called “bypass traverse checking” which allows users to access a directory path (\serverrootfolderpath), where intermediate paths are “bypassed” for “traverse checking” (validating the traverse/execute right is granted). OneFS does not enforce Microsoft GPO set forth in Active Directory, but implements “bypass traverse checking” through the existence of an NTFS ACL.

Some customers may wish to disable “bypass traverse checking” so as to enforce checking of the traverse permission on each intermediate directory, thereby enforcing an ‘Access denied” when the permission is not granted explicitly.

Though Isilon OneFS has the ability to build a custom ACL policy via the WebUI or the CLI (in 8.x+ only), control of traverse checking is not visibly available as a configurable parameter or option, though a kernel level ACL policy does exist to alter the behavior described above (require an explicit traverse permission when an ACL exists).

Contact Isilon Support, open a case, and reference this KB for further assistance.

The ability to alter the behavior through the UI/CLI interface will be added in a future major release of OneFS.

Related:

NTFS unmount problem

I need a solution

Hi

my employe used Endpoint Encryption Desktop 10.3.x on his Win7Pro(64-bit) notebook and everything was fine. The secure data keeped in virtual PGP NTFS file on notebook hard drive.

But recently he moved his data on a new Win10Pro(64-bit) notebook and since that he can’t unmount his ntfs file, the error pops up every time:

“NT driver file request operation failed”. And PGP disk still mounted in explorer.

The things i tried:

1. made a new NTFS PGP file and move data into it – no help

2. update his PGP software to late release(10.3.12) – no help

3. granted administrative privileges to his account – no help

4. mount pgp disk as Folder – no help

5. update PGP software to another release 10.4.1 – no help

i checked file permissions from this discussion: https://www.symantec.com/connect/forums/unable-unmount-pgp-virtual-disk

and this user has full rights and he is `owner` also.

6. disable AV software – no help

There is no much info about this problem in internet, and im going nuts with this it. can someone help with this?

p.s. as a temporal solution i made a FAT32 PGP virtual drive and move secure data into it. this kind of drive unmounts with no error. but me presonally dislike this kind of solution because of fat32 restrictions.

V.

0

Related:

  • No Related Posts

EMC SourceOne Email Management File Restore Activity fails with “Permission Error (0x86044710).”

Article Number: 483073 Article Version: 2 Article Type: Break Fix



SourceOne for File Systems

When trying to restore the files previously shortcut, using File restore activity, the following file permission-related error shows:

Unable to verify that the user has required file system permissions to restore the file. Try restoring to an alternate location. (0x86044710)

Function: CExFileSystem::iWriteFileProperties

Error encountered checking permissions (0x80070423)

Function: CoExFileProvider::StoreDoc

Failed to restore file to original location

(000000002FA2F179A9A64B3E18708A1301F6951BEA98F76600). (0x86044701) The specified property FSC_TargetLocation does not exist

(0x86044002)

The issue was related with Windows File permissions not being applied properly to the files needed to be restored. Although Windows NTFS file/folder permissions stated that a particular end user and SourceOne account had full permission on those files, somehow Windows was not applying it.

Also, when running a File Restore Activity, the following NTFS security file/folder permissions need to be configured for the SourceOne service account :

–>Local Administrators group has the following rights:

–> Backup files and directories

–> Manage auditing and security log

–> Restore files and directories

–>Take ownership of files or other objects

  1. Remove and re-add the file permissions, disabling the option “Include inheritable permissions from this object’s parent” when managing NTFS permission on the problem file server foldername.
  2. Re-add any other identified users in this manner that lost file/folder permissions

Related:

Unable to publish image, out of disk space, ELM console reports “No free mft record for $MFT: No space left on device”

First, try just expanding the image template. It’s entirely possible that the sheer size of the layers you have assigned is larger than the allotted space you have set in the Image Template.

However, if you are sure the Image Template is big enough, this might be a problem we sometimes have handling the NTFS Master File Table ($MFT), which sometimes causes the $MFT to run out of space. The $MFT is where NTFS stores file informatin, including the cluster maps, file attributes, and other meta-data. If a file is small enough, its entire contents can be stored in the $MFT instead if allocating cluster space for it. The $MFT should always dynamically resize, but sometimes it does not, leading to a spurious out-of-space issue.

However, we have found that regenerating the $MFT can help. Normally, when publishing, the OS Layer is much smaller than the published image. That allows us to clone the NTFS filesystem of the OS layer, expand it, and play in the remaining layers. Cloning the fliesystem copies the $MFT from the OS layer, including any odd issues that might be there.

But we cannot shrink a filesystem, so if ever the OS layer is actually larger than the published image, we can’t clone the NTFS filesystem and shrink it. We have to create a new, smaller disk, and copy the OS layer in the sam as we do all other layers. This allows the $MFT to be completely reconstructed. Reconstructing the $MFT during publishing in this way appears to workaround the $MFT problems we sometimes see.

To use this workaround, you need to make sure your OS layer is larger than the Image Template size. By default, OS layers are 60GB virtual disks, and templates are 100GB. If the number and size of the layers in your template is small, you could simply reduce the Image Template size to below 60GB. Otherwise, you can Add Version to your OS layer, and in the Add Version wizard, set the new OS version to be larger than the Image Template. After the Packaging Machine boots, Shutdown for Finalize, Finalize, and assign that new, larger version to your Image Template.

Since layer disks are thin provisioned inside the ELM (because they are VHD files), a 120GB disk that contains 20GB of files is exactly the same size as a 60GB disk that contains 20GB of files. So you can expand the OS layer to be whatever you need it to be, even as you reduce the Image Template as well. However, note that the larger OS layer disks may consume additional space in the Connector Cache.

Related:

ViPR Controller: Failure to expand VNX File system with VIPR Controller.

Article Number: 484639 Article Version: 2 Article Type: Break Fix



ViPR Controller,ViPR Family

When expanding a newly created file system over a VNX array, received the following error in the GUI

User-added image

The following errors are seen in the ViPR Controller Logs:

INFO VNXFileSystemMountProcessor.java (line 55) Mount task response status: ERROR

ERROR VNXFileProcessor.java (line 146) Fault response received due to FS_DATA : is mounted on /root_vdm_5/FS_DATA possible cause null

INFO VNXFileArgsCreator.java (line 1196) Mounting VNX File System

INFO VNXFileArgsCreator.java (line 1220) Mount file system id: 137 and isVirtual null

INFO VNXFileArgsCreator.java (line 1221) Mount file system path: /FS_DATA, Mover: 1

INFO VNXFileInputRequestBuilder.java (line 187) Time out value 5000

INFO VNXFileSystemMountProcessor.java (line 36) Processing VNX Mount response: org.apache.commons.httpclient.methods.PostMethod@4e878880

INFO VNXFileSystemMountProcessor.java (line 55) Mount task response status: ERROR

Unable to expand file system with the Error 160: caused by: File system expand exception

The above errors occur because the file system was unable to find the mount path.

Workaround:

  1. Create a test share on the faulty file system.
  2. Re-try expanding the file system again, it should finish successfully without any error.

Related: