[SOLVED] NTFS Operation Not Supported (45)

Some programs will save a file to a temp file, delete the original, then rename the temp file when saving over a file. This would cause the saved over file to be owned by the last user to edit the file.

I'm not sure what would cause 2 and 3. Does this happen with other programs, for example Notepad?

Strangely, this behaviour only seems to apply to our Microsoft Office (2003) programs. I have tested Word and Excel and they both result in problems 1,2 and 3. Notepad does not seem to modify the permissions or ACLs in any way. So it looks like Office applications that save to a Samba share are somehow affecting the execute permission and the ACLs. The execute permission thing is a bit undesirable but not the end of the world. The ACL thing would be no problem at all (in fact ACL support is probably a useful Windows compatibility feature) if it didn't also cause rsync (and cp -p as well) to generate error messages when copying files with ACLs to NTFS USB drives. So in summary, I just need a fix/workaround for Problem 3 and/or the NTFS rsync issue.

Ewok - Is there any way you could please try to reproduce the problem at your end using RAIDiator 4.1.6 (Sparc)? You just need a "user" share with two authorized users, save a word doc (test.doc) with user1 then modify with user2. You can reproduce the problem by executing

cp -p test.doc /USB_HDD_1

where /USB_HDD_1 is the mount point for an NTFS formatted USB drive. You should get the error

Operation not supported (45)

.

Can you suggest any way to stop the rsync backup from reporting a failure due to this problem every night? I had two potential ideas myself which I would like to get your input on:
1) set the SMB config option of "nt acl support = no". Presumably if this is set to "no", then no ACL's will be written, and then ntfs-3g/rsync won't complain
2) update the ntfs-3g package to the latest stable release (hopefully this version can handle ACLs)

By the way, you are correct about the cause of problem 1 (i.e. the temp file thing). I found a useful web page that mentions a potential workaround (see the last section in http://www.samba.org/samba/docs/man/Sam ... trols.html called "MS Word with Samba Changes Owner of File").

FYI - Here is the except from the web page mentioned above:

MS Word with Samba Changes Owner of File Question: “When user B saves a word document that is owned by user A, the updated file is now owned by user B. Why is Samba doing this? How do I fix this?” Answer: Word does the following when you modify/change a Word document: MS Word creates a new document with a temporary name. Word then closes the old document and deletes it, then renames the new document to the original document name. There is no mechanism by which Samba can in any way know that the new document really should be owned by the owners of the original file. Samba has no way of knowing that the file will be renamed by MS Word. As far as Samba is able to tell, the file that gets created is a new file, not one that the application (Word) is updating. There is a workaround to solve the permissions problem. It involves understanding how you can manage file system behavior from within the smb.conf file, as well as understanding how UNIX file systems work. Set on the directory in which you are changing Word documents: chmod g+s `directory_name'. This ensures that all files will be created with the group that owns the directory. In smb.conf share declaration section set: force create mode = 0660 force directory mode = 0770 These two settings will ensure that all directories and files that get created in the share will be readable/writable by the owner and group set on the directory itself.

Would it be possible to use ext3 on the USB drive? There are utilities that can read ext3 filesystems on Windows boxes.

ewok wrote:
Would it be possible to use ext3 on the USB drive? There are utilities that can read ext3 filesystems on Windows boxes.

Unfortunately that's not a great option for me. In the past on Windows XP what you suggest has been a workable (if somewhat inconvenient) solution. However on Windows-7 64-bit I spent quite a bit of time trying to get Ext2IFS or Ext2FSD to work without success. I remember trawling though all sorts of issues including trying to run in Vista compatibility mode. After many wasted hours I came to a dead-end. If you look at the Ext2IFS (http://www.fs-driver.org/) and Ext2FSD websites (http://www.ext2fsd.com/?page_id=2), neither solution even claims to support Windows-7 as of now and neither project seems to be being actively worked on recently.

In the event of a complete failure of a Readynas, the last thing that Windows-7 users need is to find that they require an installation of Linux (or to install Ext2IFS on an old XP computer) to even be able to access their USB backup. I understand that you guys are really busy and the last thing your team wants is another bug to add to an already long list (especially on a Sparc platform that you are moving away from), but surely you would agree that it is better for users if the Readynas NTFS functionality simply works as it should. I've spent quite a bit of my own time here and done everything I can here to analyze and pinpoint the bug so at this point it should be as effortless as possible for someone at Netgear to reproduce. I also have some response from the ntfs-3g developers who suggest a solution here:
http://tuxera.com/forum/viewtopic.php?f=2&t=14344

Is there any way that Netgear could please attempt to reproduce and then fix the bug? Perhaps someone could see if this problem can be reproduced on the latest x86 RAIDiator firmware (since perhaps this contains a more recent version of the ntfs-3g package according to http://www.readynas.com/?p=3728). If it works on x86, then there is some hope that applying the same update to Sparc will fix the bug. I would help, but I don't own an x86 Readynas.

After all, backing up to external NTFS drives is functionality that the Readynas is supposed to have supported since RAIDiator version 4 (viewtopic.php?t=15059)? I would think that the main purpose of NTFS support on the Readynas is for backup. And a backup solution that cannot handle Microsoft Office files seems like a fairly important bug that deserves fixing.

mjw wrote:

Is there any way that Netgear could please attempt to reproduce and then fix the bug? Perhaps someone could see if this problem can be reproduced on the latest x86 RAIDiator firmware (since perhaps this contains a more recent version of the ntfs-3g package according to http://www.readynas.com/?p=3728). If it works on x86, then there is some hope that applying the same update to Sparc will fix the bug. I would help, but I don't own an x86 Readynas.

I'll pass your info to QA and see if they can reproduce it. You may also want to open a case with support so they can try and reproduce it from their end also.

Much appreciated - thanks! Regarding support, I don't know how to open a case without paying money. The last time I spoke to support they told me that my X6 was out of warranty so I would have to pay for support. Is there some other way?

Try opening a support case online:

http://www.readynas.com/?cat=39

Ewok, as requested I have opened case number 13156877.

Over the last couple of days I've been working with the developers at Tuxera to try to investigate this problem. The full thread of what we tried is here:
http://tuxera.com/forum/viewtopic.php?f ... 4f2#p20447

Here's the summary
Frontview provides two ways of backing up to a USB NTFS drive:
1) cp -p
2) rsync -aVA

Note that both commands attempt to preserve permissions. Both commands work fine when copying any file that has only the standard UNIX file permissions and no ACLs. However, in the case of a file with ACLs, both commands fail when writing to an NTFS filesystem mounted by the ReadyNas. This is because RAIDiator 4.1.6 is not properly set up to be able to copy ACLs to an NTFS partition.

The easiest way I have found to solve the problem is to set the Samba option

nt acl support = no

for each share defined in the Samba configuration file /etc/frontview/samba/Shares.conf. Samba can be forced to re-read this file by

 /etc/init.d/samba restart

The effect of this setting is that Samba will ignore applications like Microsoft Word that attempt to modify ACLs. This means that the ext3 share will never get into the situation where it has any files with ACLs. Therefore all files will still have the standard UNIX file permissions, but there will be no ACLs. This means that the backups now function without any errors (even with the -p or -A options).

The problem I have not been able to solve is that as soon as the Readynas is rebooted, this config file is overwritten and the settings are lost. I would be grateful if you could let me know how I can make the setting survive reboots.

Of course, the ideal solution would be for RAIDiator to be properly set up to copy ACLs to NTFS (so that permissions are just as complete as when using ext3). There are a few things preventing error-free copying of ACLs in RAIDiator 4.1.6:
1) The version of ntfs-3g is too old (it needs to be updated to 2010.8.8 or later)
2) By default, ntfs-3g does not include ACL support. In order to build it in you must configure with the compile time option "--enable-posix-acls". As far as I can tell, there is no harm from setting this option even if it's not immediately used (it will only take effect of item 4 is also performed - see below).
3) In addition to the above, the Linux kernel must be at least 2.6.20 (see http://www.tuxera.com/community/ntfs-3g-faq/#fuse26) so that a decent version of FUSE is incorporated
4) In the root directory of the NTFS drive (I think this can also be configured to be elsewhere if desired) there must be a directory ".NTFS-3G" and within that directory a file called "UserMapping" containing the line

::S-1-5-21-3141592653-589793238-462643383-10000

A reboot seems to be required for this to take effect. In the ideal case the file would contain a Microsoft SID -> Unix UserID and GroupID mapping for every PC user account. This way the drive could be disconnected from the ReadyNas and moved to any PC and permissions would be perfectly maintained.

During this investigation I updated the NTFS-3G driver to 2010.8.8 with POSIX ACLs enabled (from here viewtopic.php?p=257923#p257923). This also had the nice side benefit of boosting NTFS write performance by 39% (viewtopic.php?p=258033#p258033). I have a ReadyNas X6, and on models with more powerful CPUs (NV+) the performance improvement seems to be higher.

As I mentioned before, it would be great if you could let me know how to make the "nt acl support = no" permanent.

Thanks and regards,

Mark

you could try to chattr +i the file (I don't recommend this), but a better solution would be to change files referenced by include in the config file, much the same way as the Rsnapshot add-on adds a share.

You can untar the Rsnapshot add-on bin file, and then untar the files.tgz file and take a look at the source code for the rsnapshot add-on.

Instructions are found on the forum. You can google it.

mdgm wrote:
a better solution would be to change files referenced by include in the config file

Unfortunately samba isn't configured to allow the inclusion of a user generated conf file. Would be a nice enhancement to allow persistent changes to be made as the OP requests