cp -a says Operation not permitted

[iainc]

I am trying to copy a lot of existing files from one volume/dataset to another. I ran out of space and created a new, larger zpool. I'm using cp -a and it complains "Operation not permitted". It seems that the destination file is created with an ACL, even though the source file has none. Note the + in the final ls output:

Code:

[root@freenas] /mnt/pool1/dataset1/backup# touch foo
[root@freenas] /mnt/pool1/dataset1/backup# ls -l foo
-rw-r--r--  1 root  home  0 Jan 28 14:35 foo
[root@freenas] /mnt/pool1/dataset1/backup# cp -a foo /mnt/pool2/dataset2/
cp: chmod: /mnt/pool2/dataset2/foo: Operation not permitted
[root@freenas] /mnt/pool1/dataset1/backup# cd /mnt/pool2/dataset2/
[root@freenas] /mnt/pool2/dataset2# ls -l foo
-rwxrwxr-x+ 1 root  home  0 Jan 28 14:35 foo*

I believe that both source volume/dataset and destination have the same permissions: http://doc.freenas.org/9.3/freenas_storage.html#change-permissions. And both datasets have permission type "Windows/Mac ACL". Why should creating a file create an ACL in one and not the other?

What's more, it looks like cp does not copy ACLs correctly. I would expect that cp -a would duplicate my file and duplicate the ACL, if present. I can easily set the desired non-ACL permissions manually on the destination file:

Code:

[root@freenas] /mnt/pool2/dataset2# setfacl -b foo
[root@freenas] /mnt/pool2/dataset2# chmod 644 foo
[root@freenas] /mnt/pool2/dataset2# ls -l foo
-rw-r--r--  1 root  home  0 Jan 28 14:35 foo

Why can't cp -a do that? Doing it manually is no use for the 44,000 files that I need to copy with attributes intact.

I've had a look at various forums posts such as:

https://forums.freenas.org/index.php?threads/cant-chmod-files-operation-not-permitted.22229/

Nothing I've found seems to describe my own simple problem. But permissions are confusing, even before ACLs.

(I'm on FreeBSD 9.2-RELEASE-p9 (FREENAS.amd64) #0 r262572+cc525fe: Thu Jul 3 14:22:45 PDT 2014. I've tried to upgrade to the latest 9.3 to see if it's any different. But the 9.3 installer renders my USB drive unbootable every time. I think my mobo is too old and an X10SL7-F is on order.)

 

[fracai]

I don't really have much experience with ACLs, but I'd be more interested in what the permissions are of "dataset2".

What does the following report?

Code:

ls -d /mnt/pool/dataset2

 

[iainc]

Permissions on dataset2 look fairly normal, although it does have an ACL. The source - dataset1 - is exactly the same.

Code:

ls -d /mnt/pool/dataset2
drwxrwxr-x+ 2 nobody  home  7 Jan 28 14:23 ./

(Sorry for the delay in replying. The new X10sl7-f arrived and my system was down for a few days.)

 

[fracai]

Then you also need to check the ACLs of that directory. If you aren't "nobody" or belong to the "home" group, you don't have write permission to that directory. It's that or the ACLs that are restricting you.

 

[cyberjock]

cp can't handle ACLs.. hence the failure. ;)

Let me clarify this.. CP has had problems for me that seem to be ACLs not being fully supported. To what extent I'm not sure.

 

[iainc]

Returning to an old thread - I'm still struggling with this.

> cp can't handle ACLs.. hence the failure.
I'd argue that the OS is fundamentally broken when cp doesn't work. In the example below, cp fails but I can achieve the desired result using getfacl and setfacl to copy the ACL from source to dest. The result is a copy of the file with the original's permssions, ACLs included. But cp can't do that.

Do I need to file a support ticket to ask for cp to correctly support ACLs?

Code:

[root@freenas] /mnt/WorkData2/WorkBulkData# ls -l .
drwxrwxr-x+  5 nobody    work           6 Apr 23 14:43 ./
drwxrwxr-x+  4 root      wheel          5 Mar 30 11:31 ../
-rw-rw-rw-   1 iainwork  work   734003200 Feb 17 12:50 foo
[root@freenas] /mnt/WorkData2/WorkBulkData# cp -a foo ../WorkDataSet2/Bulk/
cp: chmod: ../WorkDataSet2/Bulk/foo: Operation not permitted
[root@freenas] /mnt/WorkData2/WorkBulkData# ls -l ../WorkDataSet2/Bulk/
drwxrwxr-x+  2 nobody    work          3 Apr 23 16:05 ./
drwxrwxr-x+ 17 nobody    work         50 Apr 23 14:38 ../
-rwxrwxr-x+  1 iainwork  work  734003200 Feb 17 12:50 foo*
[root@freenas] /mnt/WorkData2/WorkBulkData# getfacl foo | setfacl -b -h -M - ../WorkDataSet2/Bulk/foo
[root@freenas] /mnt/WorkData2/WorkBulkData# ls -l ../WorkDataSet2/Bulk/foo
-rw-rw-rw-  1 iainwork  work  734003200 Feb 17 12:50 ../WorkDataSet2/Bulk/foo

 

[cyberjock]

No, because ACLs are not "static" in a fashion that cp can use. Not to mention cp uses unix permissions not ACLs.

The problem is that ACLs have 2 ways of being applied. exclusive to the file/folder (basically set by you) and inherited by the location of the file/folder. The expectation is that the server admin will manage the proper permissions, as necessary, for the server. cp is a unix application, and as such does not do ACLs because ACLs are not part of Unix permission. If you are wanting to copy files from one location to the other and keep most permissions (inherited won't "copy" over unless explicitly set via parameters to be copied and made exclusive), then you should look at rsync.

Optionally, you can choose to disable the behavior that protects your ACLs from being corrupted by unix permissions, but I'm not going to discuss how to do that here because we specifically added this feature to protect people from screwing themselves in 9.2.1.6 and I do not want people to think this is even a slightly good idea. It also won't copy the ACLs, so it wont' really solve your problem, but it will definitely create new ones. If you do go this route, it will be pretty obvious from your future threads that you did what you did, and you can expect to be ignored because most people will assume that you deserve the pain you created by going that route without an in-depth understanding of what you did. (aka, don't turn knobs and push buttons if you don't know what they do... one could be a nuclear detonation button)

 

[iainc]

Thanks for the explanation.

> you should look at rsync.
Actually, I find that rsync works less well. It fails to create some files at the destination. At least cp manages to copy all the files with incorrect permissions and I can fix them up after by copying the acls. Do I have the correct rsync invocation?

cyberjock: While reading other forum posts about ACLs, I saw you say, "I am writing a guide on how to handle permissions properly in FreeNAS, but you probably won't like it when I tell you it will be using ACLs." Did you get anywhere with that? I'd love to see it. A quick search didn't turn anything up.

Code:

rsync -Artv Drivers ../WorkDataSet2/Bulk
rsync: failed to set permissions on "/mnt/WorkData2/WorkDataSet2/Bulk/Drivers": Operation not permitted (1)
rsync: mkstemp "/mnt/WorkData2/WorkDataSet2/Bulk/Drivers/Foo/.setup.cfg.wcFeGh" failed: Operation not permitted (1)

 

[anodos]

A quick search didn't turn anything up.

That's because its release date coincides with Half Life 3.

 

[Ericloewe]

That's because its release date coincides with Half Life 3.

You mean Cyberjock is too busy making a custom Linux distro, developing VR hardware, outsourcing the creation of hats to the community, trying to monetize mods and designing semi-custom hardware to compete with established game consoles to write the Permissions guide?

 

[cyberjock]

hats?! ROFL. Where did that come from!?

No, my guide hasn't been released... at least not yet.

 

[anodos]

hats?! ROFL. Where did that come from!?

No, my guide hasn't been released... at least not yet.

He was criticizing my comparison of Half Life 3 to vaporware like your permissions guide. ;)

 

[Ericloewe]

hats?! ROFL. Where did that come from!?

No, my guide hasn't been released... at least not yet.

http://ashlelang.deviantart.com/art/Every-Hat-In-TF2-401600741

https://wiki.teamfortress.com/wiki/Hats

The visual representation is a bit out of date, though.

 

[alexg]

rsync with ACLs works just fine. Here is the command I use to copy to 3rd backup set on external drive. "-a" includes "-A" which supposed to copy ACLs. I run it as root

Code:

rsync -aiz --stats --delete /mnt/tank/shares/ /mnt/rmtank/shares