Hi all

I allready experienced this phenomenon on two servers.
Certain Files ntfs-3g can't read, it just prints out a "permission denied" message in syslog:


The "Keine berechtigung" translates to "no permission" or "permission denied".
It definetely is not a permission issue.
I mounted the filesystem as root and access it as root.

- When I access the Files in Windows I don't have any problems. And now comes the interesting part. When I copy the files to an other places and back again (overwriting the original file) ntfs-3g at once is able to read them!

- chkdsk doesn't reveal any errors

- as far as i noticed, the files usually are in the same directories or subdirectories, but not necessarly all of the files in a directory and it's subdirectories are affected.

- The system used is debian squeeze. I tried it out with following ntfs-3g versions, with the same result:
2010.3.6-1 and 2011.10.9AR.1-1

- About the system setup: windows is run in a xen virtual machine. the partitions affected so far were inside an LV (logical volume of LVM2). To access the files usually a snapshot of the LV is done (windows still running), but when switching of the virtual machine and access the fs directly it results in the same problem.

- The windows versions with which the problem appeared so far were windows sb server 2008 and 2011

- It happened on two different machines, so most propably it's not a hardware failure (specially since windows didn't had any problems accessing the files)

- we are backuping on this way severall 100 000 files, on one server the error appeared with 2 files and on the other server with may be some docents all in the same directory or its subdirectory, and 3 files in an other directory. Other files of the same directories can be accessed without any problems.

any more informations you'd need?

ps. sorry if that gets a double post, but my post didn't appear in the forum after posting it the first time and waiting for several minutes...

Hi,


I suppose "Keine Berechtigung" is the EPERM error, or "Access denied". In this context, it should not be caused by an ownership or permissions issue. The only case where this is supposed to happen is when the files are encrypted by Windows (EFS).

If you want to copy an encrypted file (without decrypting it), you may use the efs_raw option, but do not forget to associate its decryption parameters (http://www.tuxera.com/community/ntfs-3g ... s/#efsinfo).

Doing so, you have probably decrypted the files.

I have no experience with LV's, but if you are able to mount on both systems, I assume the LV settings are not to blame.

Regards

Jean-Pierre

You're my hero . It was a riddle I just didn't see any solution for...
No the only riddle left I have to solve is why one of my coworkers started about two weeks ago encrypting random files, without knowing about it (yesterday he managed to produce some more of them).



seems like you were right. Propably a better error message would help a lot in this context.


- How can I associate its decryption parameters? I can't find any information about that on this link.

- If we restore these files with ntfs-3g on an ntfs partition can they be read again (assumed the same user still exists and also his private key)?

- When we copy them in windows over e.g. nfs from an ext4 partition (that's where we store the backups on) most propably windows can't read (decrypt) this files anymore. right?

Hi,


Not possible, sorry, error returns have to be taken in a list of standard codes (as defined in errno.h)

There are similar examples in the link provided. The efs info is an extended attribute named system.ntfs_efsinfo .Copying the efs-info from source-file to target-file can be done by (efs_raw option not required) :

Of course this is only meaningful if source-file and target-file have the same contents.

To copy the data, you have to be careful to mount both source and target with option efs_raw, because the file is slightly bigger than the apparent size. Your de-DE.plg_editors-xtd_pdf.ini is probably shown as 773 bytes, but 1024 bytes are used. With efs_raw it will appear as 1026 bytes to be copied.

When using the efs_raw option, the efs info is also shown as user.ntfs.efsinfo, so that you can copy it to an extended attribute in ext4 and conversely (replace system.ntfs_efsinfo by user.ntfs.efsinfo in the example above).

In http://b.andre.pagesperso-orange.fr/tools.zip there are several tool to copy files with their extended attributes : ntfscp.c can make a direct copy from ntfs to ntfs, so does ntfscp.sh. ntfscp2.sh puts the extended attributes into specific files and should be compatible with ext4. You may have to adapt one of them.

* edit *

The copy to ext4 mentioned above is usable for a backup, but for Windows to be able to decrypt the file, it must be restored to ntfs. Windows will not be able to decrypt a remote file through nfs.

* edit 2 *

And I forgot the obvious tools : "tar --xattrs", "cp –preserve=xattr", "rsync -X" etc. can backup and restore ntfs encrypted files on ext4 provided the ntfs partition is mounted with efs_raw.

Regards

Jean-Pierre