[SOLVED] NTFS Operation Not Supported (45)

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.