FAQ SearchLogin
Tuxera Home
View unanswered posts | View active topics It is currently Sun Jun 13, 2021 04:43



Post new topic Reply to topic  [ 79 posts ]  Go to page Previous  1, 2, 3, 4
Operation not supported (45) - ACL problem 
Author Message
NTFS-3G Lead Developer

Joined: Tue Sep 04, 2007 17:22
Posts: 1286
Post Re: Operation not supported (45) - ACL problem
Hi,
Quote:
Where can I download the Sparc version?

It is on http://b.andre.pagesperso-orange.fr/adv ... l#download
To be precise this is a preview of ntfs-3g-2011.1.15 and only the options processing is different. The associated readme file indicates how to test without disturbing the existing installation.

Regards

Jean-Pierre


Mon Jan 31, 2011 10:03
Profile

Joined: Mon Sep 13, 2010 18:42
Posts: 42
Post Re: Operation not supported (45) - ACL problem
jpa wrote:
mjw wrote:
I'm still not sure I understand why ACL support is a compile-time option rather than a run-time option.

Maybe i will do it some time if there is enough demand. It will require rewriting and I will have to deal with differences among OS'es as Posix ACLs only exist on Linux and I am uneasy to get configurations right for OS'es I do not have access to.
mjw wrote:
If a company like Netgear just compiles your standard build then it's likely that ACL support will be excluded and then it will be almost impossible for users to switch on ACL support without hacking into the machine and voiding their warranty.

The "standard build" is intended for standard usage, but Netgear probably promotes more advanced features which could be reflected in their specific builds...

Hello again. I discovered today that Netgear released a new firmware version last month that updated NTFS-3G from 2010.8.8 to version 2010.10.2, however as I predicted, Netgear did not include the all-important --enable-posix-acls build option since it was a compile-time option instead of a run-time option:
RAIDiator 4.1.7 wrote:
Jan 30 09:08:46 nas-01-1D-A5 ntfs-3g[1506]: Version 2010.10.2 integrated FUSE 28
Jan 30 09:08:46 nas-01-1D-A5 ntfs-3g[1506]: Ownership and permissions disabled, configuration type 7

1. Is there any way I could urge you to reconsider changing --enable-posix-acls from a build option to a runtime option? I think this would greatly increase the likelihood that this fantastic new functionality makes it into the hands of users of embedded devices like the ReadyNAS.

2. Next is the issue of the UserMapping file. I would like to ask Netgear to include STABLE Version 2011.1.15 (January 23, 2011) into the next update (RAIDiator 4.1.8 ) but I fear that if they can't take the care to manually configure the NTFS-3G build options correctly then there is even less chance of handling the UserMapping configuration in a user-friendly yet overridable manner. I'm wondering if we can't take a page out of the Apple way of doing things and allow the functionality to simply "work" without requiring any special NTFS-3G knowledge by users or Netgear engineers.
jpa wrote:
mjw wrote:
2) A way to avoid the need for the UserMapping file. Ideally users could just plug in a USB NTFS external drive and start using it immediately without having to worry about creating any UserMapping file. Is there any reason why NTFS-3G couldn't be changed so that by default, in the absence of any UserMapping file, it behaves as if the file contains "::S-1-5-21-3141592653-589793238-462643383-10000"?

That has be done for users not using ACLs (just use the option "permissions"), but so far I do not know of a single user having used it. I will do the same for ACL users if there is a need. Just understand that most users need the identification defined by a real Windows user, and so far I know of no way to get it automatically.

Since you say that you "do not know of a single users having used" the permissions option, how about slightly modifying the meaning of the "permissions" option (to make it more useful) so that by default it also works for users who ARE using ACLs even when a UserMapping file is not present (if a UserMapping file is present, then the behaviour is overridden to be the same as the current functionality)?
Case 1 - There are no ACLs in the source file on EXT3. Result => Ownership and permissions are copied to the target file on NTFS. There will be no ACLs copied to the target file. cp -p will not return an error.
Case 2 - Ownership and permissions are copied to the target file on NTFS. There are ACLs in the source file on EXT3. Result => ACLs are copied to the target file. cp -p will not return an error.
An even better solution in my mind would be to allow ownership, permissions and ACLs to be copied by NTFS-3G as the default behaviour and then perhaps add some options for "noacl", "noownership", "nopermissions" in case it's needed in some unusual fringe usecase.

With the way that the permissions option works currently, Case 2 will result in a an error. I can't imagine any reason why the behaviour would be desired by any user yet alone the majority of users, so it doesn't seem to make sense to have that be the default behavour.

3. There is one more problem with the way things work currently. Suppose the Netgear build engineer is sufficiently knowledgable and awake to remember to change the NTFS-3G build option to "--enable-posix-acls". They mustn't use the "permissions" option because that causes errors when "cp -p" is run, so what options would they use.... If they set the "usermapping=" option to point to a default UserMapping file somewhere within the ReadyNAS main EXT3 filesystem and put this line in the file
Code:
::S-1-5-21-3141592653-589793238-462643383-10000

then "cp -p" will not return an error, which is a good default for general users. However there is now no way for advanced users to set up specific SID mappings. Am I correct in thinking that even if an advanced user creates a ".NTFS-3G\UserMapping" file on their USB drive this will be ignored because of the "usermapping=" option"?

Netgear would then need to go to the trouble (which they would almost certainly not do) of extending their user interface specifically for NTFS-3G to allow the usermapping option to be switchable, or to make the included UserMapping file editable. This would be a support nightmare for Netgear because it requires all users to understand the purpose of the NTFS-3G usermapping option (which, let's face it, is not a simple concept for the majority of users who have no linux knowledge). Netgear support will have to deal with users who accidentally unset the usermapping option, but don't add a correct UserMapping file on the USB drive, or misconfigure the UserMapping file contents and then start to get hard-to-understand errors from their backup jobs.

Am I making any sense here?


Tue Feb 01, 2011 16:50
Profile
NTFS-3G Lead Developer

Joined: Tue Sep 04, 2007 17:22
Posts: 1286
Post Re: Operation not supported (45) - ACL problem
Hi,

Quote:
however as I predicted, Netgear did not include the all-important --enable-posix-acls build option since it was a compile-time option instead of a run-time option:
RAIDiator 4.1.7 wrote:
Code:
Jan 30 09:08:46 nas-01-1D-A5 ntfs-3g[1506]: Version 2010.10.2 integrated FUSE 28
Jan 30 09:08:46 nas-01-1D-A5 ntfs-3g[1506]: Ownership and permissions disabled, configuration type 7

They did compile with --enable-posix-acls as shown by the configuration type (7 means Posix ACLs compiled in). Probably the ownership cannot be enabled because the SIDs needed to record the ownerships have not been defined (no user mapping defined).
Morever note the known bug in 2010.10.2 on big-endian CPUs such as the Sparc. With this version you can use the plain permissions, not the Posix ACLs.
Quote:
this fantastic new functionality makes it into the hands of users of embedded devices like the ReadyNAS

Such phrasing is useful for getting turned into the mood of making an effort, but the effort is still ahead. I now have an idea about who will contribute to the testing.
Quote:
how about slightly modifying the meaning of the "permissions" option (to make it more useful) so that by default it also works for users who ARE using ACLs even when a UserMapping file is not present (if a UserMapping file is present, then the behaviour is overridden to be the same as the current functionality)?

I would rather define a new option "acl" (like on ext3/ext4) to enable the Posix ACLs, either with hardcoded SIsD or with user-defined SIDs if a user mapping file is present.
Quote:
An even better solution in my mind would be to allow ownership, permissions and ACLs to be copied by NTFS-3G as the default behaviour and then perhaps add some options for "noacl", "noownership", "nopermissions" in case it's needed in some unusual fringe usecase.

If I were to change the default behavior to enabling some sort of permissions, I will trigger a riot. So this leaves me with two possibilities : use mount options and/or get options from a predefined file. When using the predefined file, users need not login as root and search for mount options (in some obscure policy file for plugged-in devices).
Quote:
With the way that the permissions option works currently, Case 2 will result in a an error. I can't imagine any reason why the behaviour would be desired by any user yet alone the majority of users, so it doesn't seem to make sense to have that be the default behavour.

The vast majority of users are FAT-nostalgic and do not want permissions to prevent accessing files (typical : download an exe with Linux, then plug into Windows to discover the file is not executable because it was created with protections 664). With current default settings, only advanced users may have such difficulties.
Quote:
Suppose the Netgear build engineer is sufficiently knowledgable and awake to remember to change the NTFS-3G build option to "--enable-posix-acls".

Well, you gave them good advices and they did it, bravo ! Just the endianness bug was in the way.
Quote:
They mustn't use the "permissions" option because that causes errors when "cp -p" is run, so what options would they use.... If they set the "usermapping=" option to point to a default UserMapping file somewhere within the ReadyNAS main EXT3 filesystem and put this line in the file
Code:
::S-1-5-21-3141592653-589793238-462643383-10000

then "cp -p" will not return an error, which is a good default for general users

Currently Netgear use no specific option and no predefined file, so users get no permission and most of them do not complain. If Netgear compile with "--enable-posix-acls", still with no specific option or predefined file, the standard user will get no change in behavior (no permissions), and the advanced user can define his user SIDs and get Posix ACLs. An interesting point is that even the advanced users need not login as root and dig into the NAS kernel to set options.
Quote:
Netgear would then need to go to the trouble (which they would almost certainly not do) of extending their user interface specifically for NTFS-3G to allow the usermapping option to be switchable, or to make the included UserMapping file editable.

In most cases it is easier to have the usermapping on the device. Has the user some documented control over the mount options ?

Note : I have developped some code to collect the user mapping from Samba, relying on wbinfo. However I think that in most cases this will fail, because the devices are generally mounted before the network is up.

Quote:
Am I making any sense here?

Sure. I feel the Netgear user has a higher level of requirements than most users, and it is difficult to best serve both with the same default option.

Regards

Jean-Pierre


Tue Feb 01, 2011 20:02
Profile

Joined: Mon Sep 13, 2010 18:42
Posts: 42
Post Re: Operation not supported (45) - ACL problem
jpa wrote:
They did compile with --enable-posix-acls as shown by the configuration type (7 means Posix ACLs compiled in).

In that case, sorry, it seems I was mistaken. I had incorrectly thought that "Ownership and permissions disabled" was referring to the compile time functionality being disabled.
jpa wrote:
Probably the ownership cannot be enabled because the SIDs needed to record the ownerships have not been defined (no user mapping defined).
Morever note the known bug in 2010.10.2 on big-endian CPUs such as the Sparc. With this version you can use the plain permissions, not the Posix ACLs.

I'm pretty sure you are correct.
jpa wrote:
Such phrasing is useful for getting turned into the mood of making an effort, but the effort is still ahead. I now have an idea about who will contribute to the testing.

[LOL] I suppose that would be fair. Let me know how I can help when the time comes for testing.
jpa wrote:
I would rather define a new option "acl" (like on ext3/ext4) to enable the Posix ACLs, either with hardcoded SIsD or with user-defined SIDs if a user mapping file is present.

That idea sounds good. So, if a UserMapping file is not present, will the behaviour fall back to the same behaviour as having a UserMapping file containing:
Code:
::S-1-5-21-3141592653-589793238-462643383-10000

If so, then I think this is perfect.
jpa wrote:
So this leaves me with two possibilities : use mount options and/or get options from a predefined file.

I think it would work either way since these options are rarely changed once initially set up but my feeling is that mount options would be preferable since otherwise it's going to be less than obvious where to look for the options. Some options will live in an NTFS-3G specific file that no one without prior knowledge can find, and other options will be accessed via the ntfs-3g command-line. I personally think the best thing would be to put all options into /etc/fstab and/or the command line so that people who can configure ext file systems will already know where to look for configuring ntfs filesystems.
jpa wrote:
When using the predefined file, users need not login as root and search for mount options (in some obscure policy file for plugged-in devices).

Actually, in the case of the ReadyNAS, that's exactly what a user would need to do since one root can gain acces via SSH to the ReadyNAS. A user like myself would probably look in /etc/fstab as the first guess and be completely clueless about where to look next. For example, at the start of this I hadn't even heard of ntfs-3g, so it would have taken me an hour of searching and googling to find a predefined file specific to NTFS-3G I think.
jpa wrote:
The vast majority of users are FAT-nostalgic and do not want permissions to prevent accessing files (typical : download an exe with Linux then plug into Windows to discover the file is not executable because it was created with protections 664). With current default settings, only advanced users may have such difficulties.

I understand your point, but didn't we discover earlier in this thread that as long as you use the default UserMapping file, Windows has full access to all the files on the USB drive so long as the user has Administrator rights? So for FAT-nostalgic users who don't care too much about security, they will get the same FAT-like behaviour as long as they are Administrator. In fact, as long as they don't specify your new "acl" option (which a FAT-nostalgic user would not) then they will also get the same FAT-like behaviour.

The NTFS needs of a ReadyNAS user are mostly motivated by the backup usecase. Just to give a little background info. Backups of the internal RAID volume can be made to a USB drive formatted as either EXT3, FAT32 or NTFS. Most drives that you buy now days come preformatted as NTFS, but 99% of users quickly give up on using NTFS for 3 reasons:
1. Backup errors they don't understand (often caused by ACLs or disallowed characters in filenames such as ':' which is common on MacOS, etc)
2. Loss of permissions, ownership and ACLs during the backup process which makes restoring very tedious
3. Slow performance (this is tolerable for incremental backups but the first full backup is painful typically taking almost a week to complete for a 2TB NAS)
Users also give up on FAT32 as soon as they find they have files larger than 4GBs. This means that in practice that the majority of users are forced to use EXT3. But EXT3 also has a big disadvantage in that Windows PC's cannot access EXT3 without a special driver and it seems that the majority of these drivers don't work on Windows-7 64-bit and aren't being developed any more.
jpa wrote:
Currently Netgear use no specific option and no predefined file, so users get no permission and most of them do not complain.

There are few complaints because most users quickly give up using NTFS-3G because it can't currently meet the requirements of a backup/restore solution for their EXT RAID file system. You can find countless posts around USB backup problems in the forums where Netgear and other users suggest reformatting the drive as EXT3. I believe with your enhancements NTFS-3G will become a viable solution for backup/restore on the ReadyNAS and other NASes too.
jpa wrote:
If Netgear compile with "--enable-posix-acls", still with no specific option or predefined file, the standard user will get no change in behavior (no permissions)
, and the advanced user can define his user SIDs and get Posix ACLs.

Yes, there will be no change in behaviour, but unfortunately the current behaviour is for cp -p to throw an error when an ACL is encountered. Unfortunately the ReadyNAS uses the command "cp -p" even when the destination filesystem does not support ACLs. I suppose it should really only use the "-p" option for filesystems that can support ownership, permissions and ACLs but it doesn't work that way at present. This is really Netgear's problem rather that NTFS-3G. I think this means that Readynas users would continue to suffer from problem 1 (above) unless you develop an easy way to provide a default user mapping in the case when a UserMapping file is not found in the USB drive .NTFS-3G folder. Perhaps your new "acl" option that you suggested above would create a simple means of specifying a better default behaviour (i.e. for the standard Readynas user when a UserMapping file has not been defined) on the Readynas.
jpa wrote:
An interesting point is that even the advanced users need not login as root and dig into the NAS kernel to set options.

It is true that looking for a UserMapping file on each USB drive provides some nice flexibility. However, I think it is valuable that you also provide the "usermapping" option so that users with lots of USB drives don't have to maintain separate UserMapping files across each drive. I doubt the usermapping option would be used on the ReadyNAS but it sounds useful for users administrating their own Linux box.
jpa wrote:
In most cases it is easier to have the usermapping on the device. Has the user some documented control over the mount options ?

At the moment, there is very little user control over the mount options. I think it's currently limited to switching off the "sync" option which is known on the ReadyNAS as "enable fast USB writes".
jpa wrote:
Note : I have developped some code to collect the user mapping from Samba, relying on wbinfo. However I think that in most cases this will fail, because the devices are generally mounted before the network is up.

This sounds useful for users in a business environment since presumably winbindd is only running if Samba is in domain mode (not user mode). Perhaps the collection of the mapping info could be delayed until the first read or write instead of attempting to collect at mount time?
jpa wrote:
I feel the Netgear user has a higher level of requirements than most users, and it is difficult to best serve both with the same default option.

I think your new "acl" mount option suggestion sounds promising especially if provides reasonable default user mappings in the absence of a UserMapping file.


Tue Feb 01, 2011 22:30
Profile
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 79 posts ]  Go to page Previous  1, 2, 3, 4


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Original forum style by Vjacheslav Trushkin.