[PLEASE JUMP HERE IF YOU WANT TO GO STRAIGHT TO THE SOLUTION]I have been struggling with a few permissions related problems and would really appreciate some help:This is my setup:- User mode permissions- A share called "lifepractice"- Two users (one called "karen" and another called "mshields")- Both users belong to the group "users"I want both karen and mshields to both have rw access to files and rwx access to directories. The users are accessing the files via windows using CIFS. I don't want any other users to have any access to files or directories.In the FrontView CIFS tab I have - Default Access: Disabled- Write-enabled users: karen,mshieldsIn the "Advanced CIFS Permission" tab I have set - Automatically set permissions on new files and folders: true - For both file and folders/directories I have set "Group rights:" to "Read/write" and "Everyone rights:" to disabled.- Enable oplocks for this share: true.In "Advanced Options" I have set:- Share folder owner: lifepractice- Share folder group: users- Share folder owner rights: Read/write [actually this is greyed out]- Share folder group rights: Read/write- Share folder everyone rights: Disabled - Grant rename and delete privileges to non-owner of files : True The problems arise when one user creates a file and then another user edits that file and re-saves it. For example:1) mshields creates the file test.doc ls -l test.doc-rw-rw---- 1 mshields users 24064 Sep 3 16:44 test.docgetfacl test.doc# file: test.doc# owner: mshields# group: usersuser::rw-group::rw-other::---So far so good.2) Next karen opens test.doc, changes it and saves ls -l test.doc-rw-rwx--- 1 karen users 24064 Sep 3 16:48 test.docgetfacl test.doc# file: test.doc# owner: karen# group: usersuser::rw-user:mshields:rw-group::rw-mask::rwxother::---This is where things seem to go wrong. Problem 1 - The owner of test.doc has changed from mshields to karen. Why does this happen? I thought that in Linux, when files are edited by a different user, the file will still retain the original user as the owner.Problem 2 - Somehow the file has gained group execute permissions. How can I stop this happening? Problem 3 - The ACLs for the file have an additional "user:mshields:rw-" entry and an additional "mask::rwx" entry that weren't present before the second edit of the file.Problem 3 causes rsync to report errors when backing up to an NTFS USB drive (see the backup-related problem http://www.readynas.com/forum/viewtopic.php?f=31&t=44972&p=255310 that this causes).I guess I can live with problems 1-3 if there's no alternative, but I really would like to avoid the rsync backup failures that are a consequence of Problem 3.Thanks for any help.

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 complain2) 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 FileQuestion: “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 = 0660force directory mode = 0770These 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=14344Is 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.

[SOLVED] NTFS Operation Not Supported (45)

39 Replies

Replies have been turned off for this discussion

mjw1
Aspirant
Oct 19, 2010
ewok wrote:

Can you summarize what needs to be done?

The NTFS-3G developer is suggesting (here http://tuxera.com/forum/viewtopic.php?p ... 252#p22886) that we try his very latest release "2010.10.2AR.1" which is downloadable here:
http://www.tuxera.com/community/ntfs-3g-advanced/

I would suggest the following steps (a Sparc development environment running RAIDiator 4.1.6 is required for this):
1. Download the source tarball
2. Build using the "--enable-posix-acls" option
3. Post the ".deb" file in this thread so that I can also try it out
4. Install the resulting deb in your ReadyNAS Sparc development/test environment
5. Attach a NTFS formatted USB drive. Then in the root directory of the NTFS drive there must be a directory ".NTFS-3G" and within that directory a file called "UserMapping" (case is important) containing the line

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

This tells NTFS-3G to handle ACL permissions. A reboot (or at least an unmount/mount) is required for this to take effect.
6. Create a file somewhere on your main "/c" ext3 partition (/tmp won't work since it isn't mounted with the ACL option)

touch test

7. Add an ACL to this file for any other user (except root) that is defined on your NAS

setfacl -m u:1234:rw- test

8. Unmount the NTFS drive

umount /USB/USB_HDD_1

9. Remount this time with debug enabled

ntfs-3g -o debug,acl,user_xattr,rw,sync,noatime,allow_other,blksize=4096 /dev/sda1 /USB/USB_HDD_1 2> /tmp/ntfg-3g.err

10. Copy the file with ACLs to the NTFS USB drive

cp -p test /USB/USB_HDD_1/

11. Unmount again (so that we stop getting debug messages in /tmp/ntfs-3g.err)
12. Post here any output/error messages that you see (e.g. Operation not supported) in this thread.
13. Post the contents of /tmp/ntfg-3g.err in this thread

It would also be very useful to repeat steps 5-11 in a ReadyNAS x86 Development environment running the latest released version of RAIDiator so we can see if the problem is limited to just the Sparc Readynas devices or also affects the x86 devices too.

As a very first step you could also run the test once on the Sparc Readynas before upgrading to the latest version of NTFS-3G just to confirm that you see the errors that I am currently seeing.

Thanks,

Mark

ewok wrote:
Can you summarize what needs to be done?

mjw1

Aspirant

Oct 19, 2010

mdgm wrote:

They won't exchange it (ReadyNAS cost money to make, support etc.) but there is a loyalty program coming
chirpa wrote:
We are working on a loyalty program, which would give you a coupon code to save some money on an Ultra.

Keep an eye on the forum.

Thanks for pointing this out. It sounds interesting, but personally for my next device I'm holding off any upgrade until I can buy something that:
1) Supports USB3 and/or eSATA
2) Is rack-mountable and quiet enough to install in my media rack in the living room
3) Costs around $1000
4) 100 MBps read/write performance for both ext3 and NTFS
5) At least 4 drives

ewok
NETGEAR Expert
Oct 19, 2010
mjw wrote:

I would suggest the following steps (a Sparc development environment running RAIDiator 4.1.6 is required for this):

I'll forward this to our build engineer and see what he can do. I was able to verify that copying a file with an ACL to an NTFS formatted drive produced an "Operation not supported" error.
mjw1
Aspirant
Oct 19, 2010
ewok wrote:

I'll forward this to our build engineer and see what he can do. I was able to verify that copying a file with an ACL to an NTFS formatted drive produced an "Operation not supported" error.

Much appreciated. Did you perform the test on a Sparc device or an x86 device? Also, what version of ntfs-3g and what version of Linux were you running?

Also if you are able to determine what version of "fuse" we are using that could also be very helpful:
http://sourceforge.net/projects/fuse/files/fuse-2.X/

Thanks
ewok
NETGEAR Expert
Oct 21, 2010
It was on an NV+ using the latest in-house firmware.
mjw1
Aspirant
Oct 25, 2010
ewok wrote:
I'll forward this to our build engineer and see what he can do.

Hi Ewok - Since about a week has passed I just wanted to check whether you ever heard back from your build engineer?

In the meantime another Readynas developer kindly built the package containing the bugfix for me ntfs-3g_2010.10.2AR2-1readynas-1_sparc.deb. I have been testing with this version and it solves the issue. With this fix it seems possible to retain ownership, permissions and ACLs (just like is possible with an EXT3 drive). This means that there are no more errors when running either cp -p or rsync -aAv.

By the end of this I realized that the existing Readynas Perl scripts (e.g. /frontview/bin/backup) would never work correctly with NTFS since they always use the -p option for cp and the -A option for rsync, both of which are invalid options for a filesystem that (prior to this fix) would not even allow chmod/chown. Probably the only reason that we didn't see these errors before was that the mount option "silent" was acting to suppress the errors. Interestingly the /frontview/bin/backup does contain a "FAT32 compatibility mode" that switches off the ownership/permissions/acl options for rsync but it looks like no such support was ever implemented for NTFS backups.

The only remaining questions/issues now are:
1. Where is the file on the Readynas that defines the mount options for ntfs-3g (I can't find it and it's not in /etc/fstab)?
2. We need to add the usermapping mount option (see NTFS-3G manual) and point it to a file somewhere on the main ext3 filesystem containing

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

At present I have manually created the UserMapping file on my NTFS drive inside a ".NTFS-3G" directory (which ntfs-3g checks for when it mounts the device). This works but you would probably be better off using the usermapping option for your official Netgear solution so that users can simply plug in any NTFS drive, and ownership, permissions and ACLs will work out-of-the-box.
3. When can this fix be rolled out to the rest of the Readynas community?

Thanks,

Mark
ahpsi1
Tutor
Oct 25, 2010
Wow, I am thoroughly impressed with how well you have documented and ultimately solved your problem with assistance from Netgear and other helpful developers.

mjw wrote:
I would suggest the following steps (a Sparc development environment running RAIDiator 4.1.6 is required for this):

ewok wrote:
I'll forward this to our build engineer and see what he can do. I was able to verify that copying a file with an ACL to an NTFS formatted drive produced an "Operation not supported" error.

ewok wrote:
I'll forward this to our build engineer and see what he can do.

ewok

NETGEAR Expert

Oct 25, 2010

mjw wrote:
ewok wrote:
I'll forward this to our build engineer and see what he can do.

Hi Ewok - Since about a week has passed I just wanted to check whether you ever heard back from your build engineer?

Not yet. Keep in mind his work queue is huge. :)

mjw wrote:
1. Where is the file on the Readynas that defines the mount options for ntfs-3g (I can't find it and it's not in /etc/fstab)?
2. We need to add the usermapping mount option (see NTFS-3G manual) and point it to a file somewhere on the main ext3 filesystem containing
::S-1-5-21-3141592653-589793238-462643383-10000
That would probably be in the USB mounting scripts.

mjw wrote:

3. When can this fix be rolled out to the rest of the Readynas community?

No ETA as of yet.

ewok
NETGEAR Expert
Oct 29, 2010
So I tested the build of ntfs-3g and got the invalid argument error with cp like you mentioned in the other thread. rsync doesn't seem to error out though. cp-based backups will still fail.

mjw1

Aspirant

Oct 30, 2010

ewok wrote:
So I tested the build of ntfs-3g and got the invalid argument error with cp like you mentioned in the other thread. rsync doesn't seem to error out though. cp-based backups will still fail.

ewok wrote:
So I tested the build of ntfs-3g and got the invalid argument error with cp like you mentioned in the other thread. rsync doesn't seem to error out though. cp-based backups will still fail.

Both cp and rsync worked in my tests so there must be some difference in our respective setups. It is possible to get the "invalid argument" error if you miss out step 5 in the instructions a couple of posts back. The error occurs when you execute a command that attempts to copy ACLs but you have not provided NTFS-3G with an ACL mapping file. I've also seen the same error when using any version of NTFS-3G except the absolute latest (ntfs-3g_2010.10.2AR2-1readynas-1_sparc.deb). Any earlier version still contains the bug. My suggestions would be to install this actual version rather than the one built by your build engineer at least initially so that we are certain to be running the same code.

You can also easily check the version as follows (but this doesn't immediately tell you if the Posix ACL compilation option was used):


# ntfs-3g --version
ntfs-3g 2010.10.2AR.1 integrated FUSE 28

Did you create your "UserMapping" file within the ".NTFS-3G" subdirectory and include the correct string? If not, then please try again after doing that.

Also, are you certain that the driver was compiled with the option to enable ACLs ("--enable-posix-acls" )? You can check if UserMapping has been specified and Posix ACL support is compiled in by mounting in "debug" mode using a mount command such as:


umount /USB/USB_HDD_1
ntfs-3g  -o debug,user_xattr,rw,sync,noatime,allow_other /dev/sda1 /USB/USB_HDD_1 2> /tmp/ntfs-3g.err

The driver will output something similar to the following into /tmp/ntfs-3g.err:


utime_omit_ok: 0
Version 2010.10.2AR.1 integrated FUSE 28
Mounted /dev/sda1 (Read-Write, label "OneTouch4", NTFS 3.1)
Cmdline options: debug,acl,user_xattr,rw,sync,noatime,allow_other,blksize=4096
Mount options: acl,rw,sync,allow_other,allow_other,nonempty,noatime,fsname=/dev/
sda1,blkdev,blksize=4096
User mapping built, Posix ACLs in use, configuration type 7
unique: 1, opcode: INIT (26), nodeid: 0, insize: 56
INIT: 7.8

If everything is working as expected you should see a line that says User mapping built, Posix ACLs in use, configuration type 7

Regards,

Mark

Forum Discussion

[SOLVED] NTFS Operation Not Supported (45)

39 Replies

Related Content

SOLVED: ReadyNAS Backups of new Windows 11 PC

MS510TXM, fan status, operating temperature!

Netgear Nighthawk RAX50V2 - Access Denied Bug SOLVED SOLUTION

High Operating Temp Environment

A6210 operating @ High Speed (USB 2.0)

NETGEAR Academy

ProSupport for Business