NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
[SOLVED] NTFS Operation Not Supported (45)
[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,mshields
In 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
So far so good.
2) Next karen opens test.doc, changes it and saves
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.
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,mshields
In 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.doc
getfacl test.doc
# file: test.doc
# owner: mshields
# group: users
user::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.doc
getfacl test.doc
# file: test.doc
# owner: karen
# group: users
user::rw-
user:mshields:rw-
group::rw-
mask::rwx
other::---
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.
39 Replies
Replies have been turned off for this discussion
mdgm wrote: you could try to chattr +i the file (I don't recommend this)
I'm not sure I understand how this would help. According to this article it would make files write-protected (http://www.mynitor.com/2010/08/25/the-i ... r-command/) so users would not be able to modify the file at all. What I really need is a way to only prevent ACLs being modified but to allow all other modifications. So users can create and modify Microsoft word documents, but the files only get imbued with vanilla unix file permissions rather than ACLs.mdgm wrote:
, 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.
Are you referring to the files included from /etc/samba/smb.conf, for example /etc/frontview/samba/Shares.conf?- A further update
I performed all my testing of the aforementioned "nt acl support = no" solution via Readynas Remote since my X6 is now at my sister's house in England but I am in the U.S. Unfortunately it seems that while this works fine for MS Word edits via RNR, this setting prevents Windows XP users from even mapping network drives. The result is they are completely cut off from the Readynas so I have had to revert to the former setting. So it seems that I still don't have a solution.
At this point I am running out of ideas. If there is a way to configure Samba to filter out ACLs while still allowing access using standard UNIX permissions, it's beyond my knowledge of Samba. According to Tuxera, this error cannot be fixed until Netgear updates to a more recent Linux kernel. When the developer learned that RAIDiator is running Linux 2.6.17 he responded:There are two different issues here :
First : the ACLs are not fully implemented. This has nothing to do with ntfs-3g or fuse, we can see that it is not able to show the presence of an ACL even on ext3.
Second : fuse is probably unsafe (unless the fuse kernel module has been upgraded). I think the problem is that umount does not wait for all dirty pages to be written to disk, and this is probably not acceptable for your needs.
His first point refers to the fact that when you do ls -l on a file with ACLs in RAIDiator 4.1.6 you don't even see the '+' character that should be present after the rwx permissions. This indicates that ACLs aren't even fully implemented in this version of the linux kernel.
Fuse is a Linux driver that allows IO subsystems like ntfs-3g to run in user space.
So it is looking like there are only two solutions remaining:
1) Netgear upgrades RAIDiator with kernel >= 2.6.20 and includes ntfs-3g 2010.8.8 (with the "--enable-posix-acls" option)
2) Netgear provides some configurability in frontview so that backups can be set up that don't preserve permissions (for both cp and rsync)
Any comment from ewok as to the near-term feasibility of either option?
Thanks! - #2 is probably more likely. I'll file a bug for it, but it will probably go into 4.1.8 at the earliest. This might be fixable short term with an addon.
ewok wrote: #2 is probably more likely. I'll file a bug for it, but it will probably go into 4.1.8 at the earliest. This might be fixable short term with an addon.
Hi Ewok,
I have been trying to troubleshoot this problem with the NTFS-3G developer from Tuxera.
http://tuxera.com/forum/viewtopic.php?f=2&t=14344
In order to pinpoint the cause of this problem he needs someone with a Sparc Readynas development environment to try a beta version of NTFS-3G that he has produced. It's not really feasible for me to do this since I don't have a development environment and I can't really afford to break my Readynas. He says he has some hope that this version will work on an old 2.6.17 kernel.
Is there anyone from your development team who would be willing to read the thread I have linked above and spend a bit of time working with myself and the NTFS-3G developer to try to get to the bottom of this?
Many thanks,
Mark- We are willing to help, but how stable is this build? Changing ntfs-3g would require a lot of testing from our side, and I'd hate for other users to have problems with their NTFS access.
ewok wrote: We are willing to help, but how stable is this build? Changing ntfs-3g would require a lot of testing from our side, and I'd hate for other users to have problems with their NTFS access.
At this point I am not asking that you even roll this version into RAIDiator. I'm simply asking that you help work directly with the NTFS-3G development team to troubleshoot the issue (at the moment we don't really know where the problem is) and identify a fix. Once this is done we can address the next step of whether or not this should be rolled out to users. Who knows, the problem might not even require a new version of NTFS-3G. We'll never know unless we do some tests.
Regarding stability of newer versions of NTFS-3G, I think this is a question best asked to the NTFS-3G development team (here http://tuxera.com/forum/viewtopic.php?f=2&t=14344) if we determine that a newer version is indeed necessary. Personally, I have been running my X6 with "STABLE Version 2010.8.8 (August 8, 2010)" for a month (compiled with the ACL option enabled) with no new issues (unfortunately it still didn't solve the bug mentioned in this thread, but perhaps a later version might help). I am running an incremental rsync backup running every night to a USB attached NTFS drive so the driver has been exercised a fair amount.
From a user perspective based only on performance I think there is more to gain by upgrading than there is to lose. It seems that upgrading improves NTFS write performance by 48%. The slow NTFS performance together with the error messages has probably dissuaded the vast majority of users from even using NTFS so I doubt there are many users that would even be using NTFS as it currently stands on ReadyNAS devices.- CPU is still a major bottleneck on Sparc ReadyNAS devices. NTFS backup performance is better on the x86 ReadyNAS which use Intel CPUs. If there is a performance gain that's good, but performance is still going to be poor on Sparc ReadyNAS. On Sparc ReadyNAS using EXT3 is a good way to go. Enable Fast USB Writes on the NAS and install drivers on the PC to be able to use EXT3.
mdgm wrote: CPU is still a major bottleneck on Sparc ReadyNAS devices. NTFS backup performance is better on the x86 ReadyNAS which use Intel CPUs. If there is a performance gain that's good, but performance is still going to be poor on Sparc ReadyNAS.
Yes, I realize that the Sparc performance will always be less than x86. If Netgear offers to exchange my X6 for a 4 drive x86 version then I'd definitely sign up immediately, but unfortunately I think I'm stuck with a Sparc NAS like many others ;-) In which case I'd welcome a 48% performance improvement.mdgm wrote:
On Sparc ReadyNAS using EXT3 is a good way to go. Enable Fast USB Writes on the NAS and install drivers on the PC to be able to use EXT3.
As far as I know there are no EXT3 drivers that are capable of read/write are supported on Windows 7 64-bit. I spent a lot of time trying to get them to work to no avail.mjw wrote:
At this point I am not asking that you even roll this version into RAIDiator. I'm simply asking that you help work directly with the NTFS-3G development team to troubleshoot the issue (at the moment we don't really know where the problem is) and identify a fix. Once this is done we can address the next step of whether or not this should be rolled out to users. Who knows, the problem might not even require a new version of NTFS-3G. We'll never know unless we do some tests.
Can you summarize what needs to be done?mjw wrote:
Yes, I realize that the Sparc performance will always be less than x86. If Netgear offers to exchange my X6 for a 4 drive x86 version then I'd definitely sign up immediately, but unfortunately I think I'm stuck with a Sparc NAS like many others ;-)
They won't exchange it (ReadyNAS cost money to make, support etc.) but there is a loyalty program comingchirpa 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.mjw wrote:
In which case I'd welcome a 48% performance improvement.
Understandable. Still even with a 48% performance improvement (if achievable) performance would still be very poor.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
