Joined: Mon Sep 13, 2010 18:42
Posts: 42

Operation not supported (45) - ACL problem

I am getting the error 'Operation not supported (45)' when trying to copy microsoft office (Word) files from an ext3 filesystem to an NTFS file system using ntfs-3g 2009.4.4.
The ext3 system is mounted using Samba to a Windows XP machine. The problem occurs where one user creates a word doc and then a different user edits the doc and resaves. Then when a backup job attempts to copy the word doc from the ext3 filesystem to the NTFS file system an error occurs.
For example:
1) mshields creates the file test.doc

So far so good.
2) Next karen opens test.doc, changes it and saves

Next I copy to an external NTFS USB drive, preserving the permissions (-p)

and get the error

Is this a known bug?
Thanks for any help.

Joined: Tue Sep 04, 2007 17:22
Posts: 1286

Re: Operation not supported (45) - ACL problem

Hi,

ntfs-3g 2009.4.4 did not support individual permissions. If you want them, you have to upgrade.

Even such ACLs are supported (with recent versions), if you configure ntfs-3g with --enable-posix-acls.
Regards
Jean-Pierre

Many thanks for the quick and useful response.
Actually I am having this problem with a Netgear ReadyNAS device than uses ntfs-3g internally. What release of ntfs-3g would I need to ask Netgear to upgrade to?
Is the '--enable-posix-acls' a compile-time or a run-time configuration option?
Separately, I was also wondering whether there might be another workaround to temporarily solve this problem. This individual permissions only appear when Microsoft Word modifies a file via a Samba shared drive. Do you know of any way to configure Samba so that it will ignore the ACLs (i.e. not save them to ext3). I'm thinking that if we can avoid any ACL's being saved to ext3 then ntfs-3g 2009.4.4 will not report any error.

Joined: Tue Sep 04, 2007 17:22
Posts: 1286

Re: Operation not supported (45) - ACL problem

Hi,

... to the latest stable version, currently ntfs-3g-2010.8.8

It is a compile-time option.

You did not indicate where (on Linux or XP) are the mentioned users sitting in 'The problem occurs where one user creates a word doc and then a different user edits the doc and resaves.', on which computer is the backup program executing, and to which computer and how is your NAS device connected.
I may make improper assumptions, but you apparently have the problem with the backup program doing a 'cp -p <from-local-ext3> <to-local-or-remote-ntfs-3g>'. This is apparently executing on Linux and has nothing to do with Samba, just remove the -p option.
Regards
Jean-Pierre

The users are on various Windows PCs. They create, and edit Microsoft Word documents on their PC and then save to a Windows drive letter that is mapped to a directory on a RAID ext3 filesystem inside the NAS. The NAS is running Linux and exposes the ext3 directory using Samba (User->Windows->Samba->Ext3). The backup program is running on the NAS and periodically copies from the ext3 filesystem to the NTFS filesystem of an external USB hard drive (Ext3->ntfs-3g->NTFS). In the case where the NAS fails completely, the windows users can recover their files easily by just detaching the USB hard drive from the NAS and connecting to a Windows PC (User->Windows->NTFS).

Unfortunately, the command-line options that the backup program uses are not configurable via the NAS backup user interface so I have to live with 'cp -p'. I believe that these commands are kept within encrypted perl scripts on the NAS device.
ntfs-3g 2009.4.4 does not output any errors in case 1 (see above) where getfacl returns only one 'user' and zero 'mask' lines. But in case 2 (see above) it fails. So I am thinking - how is it that the ACLs get added to the file? And my conclusion is that it must be Samba that is adding them. So I was thinking that if I can somehow stop Samba from saving ACLs, then I can prevent the problem before it even reaches ntfs-3g.
I have read that there is a Samba option to switch off ACLs

There is some info here about using this option:
http://aisalen.wordpress.com/2007/08/10/acls-on-samba/
I do potentially have the ability on the NAS to login via SSH and edit the smb.conf file.

Joined: Tue Sep 04, 2007 17:22
Posts: 1286

Re: Operation not supported (45) - ACL problem

Hi again,

Ok, fine, this is a local copy not involving Samba.

This is probably because in case 1 there are just plain permissions (just owner/group/other), whereas in case 2 there is an ACL (the user 'mshields' different from owner 'karen' has rw rights), and setting an ACL is technically not the same as setting the permissions (neither being preserved with ntfs-3g-2009.4.4).

Samba tries to emulate Windows permissions on a file system with a different logic. What probably happens is that the user modifying the file asks (rather the program he uses asks...) to be added to the list of users allowed to modify it, without depriving the original owner of his own rights. Samba just tries its best to represent the Windows requirements with Linux concepts.

This will probably force Samba to use more lossy translations, and this might not meet your security policy. In particular, Samba will have to choose between the original user and the second user as the owner of the file.
Regards
Jean-Pierre

So, I tested 2010.8.8 configured with '--enable-posix-acls' and it still didn't work

I still get the error

Is there any way you could try the same sequence of commands and let me know if you get the same error as me?
Thanks,
Mark

One more thought - do I need to add 'acl,user_xattr' to /etc/fstab?

Joined: Tue Sep 04, 2007 17:22
Posts: 1286

Re: Operation not supported (45) - ACL problem

Hi,

Short answer : create a hidden directory named .NTFS-3G in the root of the ntfs file system, and in this directory create a file named UserMapping, with the following single line :

then unmount and mount again.
This should be enough for backing-up with protections and ACLs and restoring through ntfs-3g and Samba.
For more explanations, 'man ntfs-3g' or http://www.tuxera.com/community/ntfs-3g ... rmissions/
Long answer : note that if you unplug the ntfs device and plug it on a user's Windows PC, Windows will not recognize the files as owned by the user, and as in your samples your files are not world-readable ('other::---'), they would have to be restored by an administrator.
To get the original Windows identification of users recorded in ntfs, you have to collect them on Windows and put them in the UserMapping file. On Windows XP you can get the users indentification from the names of the subdirectories of
'/Documents and Settings/<user>/Application Data/Microsoft/Credentials'
On my XP computer I get :

The id of the user is the one which ends with a number above 1000, and the line to put into UserMapping (leaving the generic line shown above as the last line) would be :
user::S-1-5-21-2271520284-214583110-2989893066-1007
If you have a lot of users, this may be boring, but the information must be available in some Samba configuration file, as Samba does the reverse translation (please return your findings...).
This may be cryptic at first, but do not hesitate to ask for help.

No, you need not, the use of ACL is triggered by the UserMapping file.
Regards
Jean-Pierre

I created the file exactly as you specified

then I unmounted

and remounted

After the remount I got this error:

Please could you let me know what this error means? Do I have a problem?
I then tried the cp -p test again and got the same error as before:

So this didn't seem to help. Any ideas?
Thanks,
Mark

Joined: Tue Sep 04, 2007 17:22
Posts: 1286

Re: Operation not supported (45) - ACL problem

Hi,

This is wrong, .NTFS-3G should be a directory, containing a file named UserMapping (you should have /USB/USB_HDD_5/.NTFS-3G/UserMapping)

Well, ntfs-3g opened the directory .NTFS-3G which was not a directory, hence the error.
Just delete the file and create a directory.
Regards
Jean-Pierre

Sorry about misunderstanding the hidden directory. I have now set up the UserMapping file within the hidden directory

Now when I attempt the cp I get a different error:

Interestingly it seems that despite cp -p returning an error:
1) the file contents are copied correctly
2) the unix user and group ownership matches
3) unix permissions are also copied correctly (e.g. -rw-rwx---)
The only thing I can see that doesn't match between the original file (on ext3) and the copied file (on ntfs) is getfacl. On ntfs, getfacl always returns:

It doesn't show any ACL information, it just says 'Success'.

Joined: Tue Sep 04, 2007 17:22
Posts: 1286

Re: Operation not supported (45) - ACL problem

Hi,
What exactly is your mount point ?
You apparently mounted with :

So I expected your mount point to be /USB/USB_HDD_5
But in your latest post, you use /USB_HDD_5 :

Is this on a NTFS device ?
Regards
Jean-Pierre

Joined: Tue Sep 04, 2007 17:22
Posts: 1286

Re: Operation not supported (45) - ACL problem

Hi again,

Strange. Can you make other tries on non-root directories ? Also do not forget that only the owner (and root) can change the permissions, the ACLs or the timestamps of a file.
Note : the root directory normally has an ACL so that only root can create files at top level.
Regards
Jean-Pierre

Yes /USB_HDD_5 is simply a symbolic link to /USB/USB_HDD5

All files on the USB drive have the same result

Also here's some version info in case its useful
[code]
tera:/c/lifepractice/Life Practice/client records/Badini# getfacl --version
getfacl 2.2.23
tera:/c/lifepractice/Life Practice/client records/Badini# uname -a
Linux tera 2.6.17.8ReadyNAS #1 Tue Jun 9 13:59:28 PDT 2009 padre unknown
[code]

Joined: Tue Sep 04, 2007 17:22
Posts: 1286

Re: Operation not supported (45) - ACL problem

Hi,

This is the culprit : an old kernel, with ACL not fully implemented. Moreover, using fuse and a kernel older than 2.6.20 is discouraged (see http://www.tuxera.com/community/ntfs-3g-faq/#fuse26)
Actually this could be seen on your initial post : the ACL was not reported to ls though on ext3, not using fuse or ntfs-3g :

ls should have reported as follows (notice the + to report the presence of an ACL)

So you either have to restrict to only use permissions, or to upgrade.... I would be sorry if the story ends here.
Regards
Jean-Pierre

Thanks for all your help. Although we don't have a solution, at least I now understand the problem much better.
So in summary, this is how the problem is occurring:
1) When user2 saves a word doc created by user1 on an ext3 Samba share, it causes Samba to add ACLs for user1 into the file
2) When cp -p is run to copy the file from ext3 to ntfs it not only attempts to preserve the standard linux permissions and ownership, it also attempts to preserve the ACLs too.
3) ntfs-3g requires a special .NTFS-3G/UserMapping file to be present in the root directory of each NTFS filesystem. Without this UserMapping file ntfs-3g, cp -p will return an error and the copy of the file not only loses the original ACL information, it also loses the user/group ownership and the file becomes owned by root
4) ntfs-3g also requires a Linux kernel >= 2.6.20 to properly support ACLs but the ReadyNas currently is at 2.6.17
Possible workaround ideas
A) Find a way to prevent Samba writing ACLs in the first place
B) Ask Netgear to change their backup script so that the '-p' option of cp and the '-A' option of rsync is configurable by users.
C) Is there any way to configure ntfs-3g (either through config, fstab or compilation) so that it doesn't produce an error when is unable to write the ACL (i.e. it silently continues as if nothing is wrong)? For example, maybe some override to tell it never to write ACLs. This way cp -p we would get all the benefits of retaining the UNIX user/group ownership and permissions in the copy without any of the error messages.
D) Ask Netgear to upgrade to a later version of Linux
Regarding workaround C - Is this something that you could potentially implement?
Also, I was wondering about a few things to make NTFS-3G a bit more user-friendly:
1) Could ACL support be compiled into NTFS-3G by default rather than requiring a special configure '--enable-posix-acls'?
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'? I think this would seem to be more reasonable than the current behaviour of returning the error 'Operation not supported'.
Also you asked me to look into something:

I did some investigation of how Samba stores these mappings. I think that it is possible to run a Samba process called winbindd that allows Linux to query SID user and group mappings from a Windows Domain server. If this is configured properly then Samba provides a 'net' command that allows you to extract all sorts of info including SIDs (see http://www.samba.org/samba/docs/man/Sam ... #id2603875).

In my case I do not have a Windows Domain server, but I can avoid Samba needing this by ensuring the the Windows username and password matches the Linux username and password. If user 'mark' has a windows login on two different PC's, as long as he has the same username (mark) and password, everything on the Samba side will work correctly.
If instead we were using SIDs and winbindd (this would have advantages for organizations with Domains and lots of users so you can avoid having to synchronize password changes between Windows and Linux) I suppose that mark might have two different SIDs (one for each PC) so I'm not sure how Samba knows in this case that both SIDs relate to the same unix user. I guess that is probably the purpose of the 'net idmap'.
Regards,
Mark

Joined: Tue Sep 04, 2007 17:22
Posts: 1286

Re: Operation not supported (45) - ACL problem

Hi,

Are user1 and user2 in the same group (the default one, from the Linux point of view) ? If so the ACL is not needed.

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 ls 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.

Check how Samba behaves when users are in the same group (ACL not needed in your examples where owner and group have rw- rights).

I do not think ntfs-3g is at stake here. The Posix ACLs are fully implemented and ntfs-3g probably throws no error. What most probably happen is that the ACLs settings issued by cp do not reach ntfs-3g, either because they are not fully implemented in the kernel (see the ls example) or because they are not implemented in fuse.

No idea at the moment, but I can check how kernel 2.6.19 behaves.

That could of course be done. It would just add complexity for most users.

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.

I am very interested in this, but I have no access to a real Samba configuration with multiple users. I need cooperation of someone with a real such configuration.

Can you post your dumpfile.txt ? If it contains confidential information, you can forge them and/or send them through PM. If it contains what I need, I can retrieve them by issuing a popen('net idmap dump <full_path_and_tdb_filename>','r') without creating any dependency on Samba.

If the SID of the users are only stored on Windows and never sent to Linux (with only the user name and group name being sent), I cannot write them to disk the same way as Windows would do locally.

If you have the same user name on two different Windows computers which are not synchronized (not in the same domain), they have different SID, and one Windows computer will not recognize the ownership of files created on a different Windows computer. You can easily check this with USB keys formatted as NTFS.
Regards
Jean-Pierre

Joined: Tue Sep 04, 2007 17:22
Posts: 1286

Re: Operation not supported (45) - ACL problem

Hi again,
Just an extra bit of information : I have made a test with kernel 2.6.19 and the 'cp -p' works perfectly (ls also shows the presence of an ACL). So you appear to be out of luck with kernel 2.6.17.
The details of the test are attached.
Regards
Jean-Pierre

Yes, they are in the same Linux group called 'users'. I'm pretty sure that the ACL is not needed, but Word seems to try to add one regardless and unfortunately I can't find a way to stop Samba from complying.

Is there any command I can type to find out the version of fuse? I'm curious to know.

They are in the same group. I thought that the Samba config 'nt acl support = no' might help, but it seems to completely prevent Windows XP users from connecting to the share. I think I would need advice from someone with much better Samba knowledge than myself to find a way to stop Samba writing ACLs.

Does ntfs-3g use /etc/fstab for defining the options 'acl' and 'noacl' for a filesystem where no ACL support is needed? That way users could always use an ACL-capable version of ntfs-3g and decide on a case by case basis which filesystems to use ACLs on and which filesystems to not use ACLs? Perhaps I'm misunderstanding something, but I think this would be better than using a compile-time option '--enable-posix-acls'.

I wish I could help you here, but this file does not exist on my NAS because I am running it in Security Mode 'User'. My guess is this file would only be created by Samba when running in Security Mode 'Domain'. There is a description of the various modes here (http://www.samba.org/samba/docs/man/Sam ... #id2559114). For home or small business use people tend not to use Domain mode because you need to have a Domain server running somewhere. In order to test this yourself you would need to setup a 'Primary Domain Controller'. If you have a linux environment, I think your best bet is to install Samba since Samba can be configured to act as the PDC (http://www.steve-lacey.com/blogarchives ... wind.shtml). Then you could try out all of the 'net' commands to your hearts content!

If the Samba Security Mode = 'User' then I'm pretty sure that there are no SIDs available. In this scenario it probably makes sense for ntfs-3g to run in 'permissions' mode rather than 'full SID mapping mode'. But can you at least write the unix user and group permissions to the NTFS file so that the NTFS backup drive could be used to restore files back to ext3 if required?

Joined: Tue Sep 04, 2007 17:22
Posts: 1286

Re: Operation not supported (45) - ACL problem

Hi,

First, understand there are two parts in fuse : a user-space library and a kernel module. You are not using the original user-space library, but the one provided by ntfs-3g, as shown by your previous posts. The problem lies with the kernel module whose version is associated with the kernel. The kernel module is located in
/lib/modules/<kernel version>/kernel/fs/fuse/fuse.ko When I filter this file with 'strings', I can see 'srcversion=F1655A7852D3D4DAADBE3A1' which is probably a reference to a commit from which the source version can be established (at least in theory). The timestamp of fuse.ko may give a minimal information.

And did you try mounting your ext3 partition with option noacl ?

You can prevent ntfs-3g from using the ACL by mounting with option 'permissions' (even if you have compiled with --enable-posix-acls). But this will probably not change anything, 'cp -p' will still complain for not being able to copy the ACL.
By the way, can you make an ACL copy from ext3 to ext3 ? Also please confirm that 'ls -l' does not show the presence of an ACL on ext3, just to locate where the ACLs are dropped.

I know that, and I have already posted here a script to produce the UserMapping file automatically, but this is only based on my interpretation of what I could get, and nobody with an actual configuration has reported anything...

Yes, I can build a configuration which works... but I will still have to make sure that this is what the users want... and if I understand correctly that would not be what you need !

Bad news.

And that is the default configuration for ntfs-3g (not using --enable-posix-acls and mount with option 'permissions').

Yes ntfs-3g can, you have even checked that. But in your situation you are also trying to copy an ACL, and the request does probably not reach ntfs-3g.
Also, what processor are you using ? (if big endian, I may have another explanation).
Regards
Jean-Pierre

Joined: Tue Sep 04, 2007 17:22
Posts: 1286

Re: Operation not supported (45) - ACL problem

Hi again,
If you are using a big-endian processor, it might be helpful if you try :
http://b.andre.pagesperso-orange.fr/ntf ... .8AA.8.tgz
configure with --enable-posix-acls and do a first try with a ntfs partition with no important data.
*edit*
Before doing the above test, can you make a simple check to make sure the ACL settings reach ntfs-3g. Simply try to do a setfacl on a NOT OWNED file. This must of course NOT be done as root :

In this situation (ACL enabled), the EPERM error is thrown by ntfs-3g. This proves the setfacl command reaches ntfs-3g (and if it does not, the test version above is irrelevant).
Regards
Jean-Pierre

Joined: Tue Sep 04, 2007 17:22
Posts: 1286

Re: Operation not supported (45) - ACL problem

Hi,
I have hope for you : I have burnt an old live-CD using Linux kernel 2.6.17 (an RC version actually), and tested its behavior with ntfs-3g.8.8AR.8 (the same version I suggested you try).

There is a difference with what you get, because 'ls -l' displays the '+' to mention the presence of an ACL.
I cannot easily check the actual ACL on this system, because getfacl was not installed, but I can easily check on a recent system :

So 'cp -p' copies the ACL perfectly. This is enough for your needs.
I still do not know what processor you are using. At the moment I can only imagine some data alignment problem, and if is a big-endian one, please test the special version suggested before.
Regards
Jean-Pierre