When left side contains EFS encrypted folders and files, and right side is a
Windows Server 2008 share (server joined to active directory domain, and not a
dc), FFS cannot create the right side folders. Error message is 5 "Access
Denied". Encrypted files in the left side root are copied ok, but painfully
slow.
A manual copy (in Windows Explorer) results in a prompt saying that encryption
will be lost. The prompt appears after 1-2 seconds, which seems to be about
the same amount of time that EFS adds before each file copy operation.
Investigations show that by enabling "trust for delegation" on the file
server, EFS can successfully create the folders and copy the files. They then
become encrypted on the server, which is definitely not what I want.
It's possible that I could disable EFS on the server thus forcing FFS to
behave as if the right side volume was not EFS capable (sort of like a FAT32
partition), but even if that works I'm hesitant to creating a separate GPO for
the storage servers.
Why is it that EFS can copy encrypted files (slow but still), but cannot
create the right side folder if the left side folder is encrypted? Is it a
bug?
Is there an option to turn off right side EFS encryption in FFS?
EFS encrypted folders / Windows Server 2008
- Posts: 4
- Joined: 17 Sep 2010
-
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
>Encrypted files in the left side root are copied ok, but painfully slow.
> Why is it that EFS can copy encrypted files
I'm utilizing windows default copying behvavior by using CopyFileEx with
parameter COPY_FILE_ALLOW_DECRYPTED_DESTINATION . Unfortunately this function
doesn't seem to be too clever according to this article:
http://www.codeproject.com/Articles/104527/EFS-Encryption-and-CopyFile-Ex-Why-DIY-is-Better.aspx?PageFlow=FixedWidth
This should explain poor performance.
> Error message is 5 "Access Denied"
> but cannot create the right side folder
When creating a folder FFS tries to copy metadata from its corresponding
source folder like file attributes and file times. So creating a folder at
target isn't a problem per se, but reading this metadata from ESF seems to
cause an "access denied" (I wasn't able to reproduce this error between
NTFS/ESF and a FAT drive so it may depend on other entities like WS 2008)
> It's possible that I could disable EFS to behave as if the right side volume
was not EFS capable
Not unless I roll in my own file copying routine (which would be nothing else
than yet another reinvention of the wheel)
The one thing I could do is to softly handle "access denied" by simply
creating a folder on target side without copying folder metadata from source.
The big question is whether this tradeoff is really justified: "Access denied"
errors will be gone at the cost of not copying folder metadata (like
timestamps, hidden attribute and file permissions). Especially if the user
selected "copy file permissions" it's not transparent to silently go along
without doing as advertized.
> Why is it that EFS can copy encrypted files
I'm utilizing windows default copying behvavior by using CopyFileEx with
parameter COPY_FILE_ALLOW_DECRYPTED_DESTINATION . Unfortunately this function
doesn't seem to be too clever according to this article:
http://www.codeproject.com/Articles/104527/EFS-Encryption-and-CopyFile-Ex-Why-DIY-is-Better.aspx?PageFlow=FixedWidth
This should explain poor performance.
> Error message is 5 "Access Denied"
> but cannot create the right side folder
When creating a folder FFS tries to copy metadata from its corresponding
source folder like file attributes and file times. So creating a folder at
target isn't a problem per se, but reading this metadata from ESF seems to
cause an "access denied" (I wasn't able to reproduce this error between
NTFS/ESF and a FAT drive so it may depend on other entities like WS 2008)
> It's possible that I could disable EFS to behave as if the right side volume
was not EFS capable
Not unless I roll in my own file copying routine (which would be nothing else
than yet another reinvention of the wheel)
The one thing I could do is to softly handle "access denied" by simply
creating a folder on target side without copying folder metadata from source.
The big question is whether this tradeoff is really justified: "Access denied"
errors will be gone at the cost of not copying folder metadata (like
timestamps, hidden attribute and file permissions). Especially if the user
selected "copy file permissions" it's not transparent to silently go along
without doing as advertized.
- Posts: 1
- Joined: 14 Aug 2013
With FFS version 7.3 on Win7pro64bit I experience a complete freezing of FFS when one EFS encrypted file is located in the source folder. I do not care about this bug and do not really need EFS, but need the EFS file just for SW testing. My workaround is a manual backup and exclusion of such files from FFS backups. Since there is no information for the end user about such problematic files during backup, I think this bug should be fixed.
-
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
I'm not able to reproduce this hang with FFS copying an encrypted NTFS folder to a FAT usb stick on Win7 x64. Do you have some specific steps that would allow me to reproduce this issue on my end? If not, at least some crash dump file could help to see at which point FFS is hanging:With FFS version 7.3 on Win7pro64bit I experience a complete freezing of FFS when one EFS encrypted file is located in the source folder. I do not care about this bug and do not really need EFS, but need the EFS file just for SW testing. My workaround is a manual backup and exclusion of such files from FFS backups. Since there is no information for the end user about such problematic files during backup, I think this bug should be fixed.targetforce
https://freefilesync.org/faq.php#crash
