Can't chmod files - Operation not permitted

[cyberjock]

Yeah, 9.3 doesn't work like that. ;)

 

[demon_devil]

See if Rogla solution on this very same thread is what you need.

And no, I didn't fixed it by rebuilding the cache. I rebuilt the cache (why not?) and I mentionned nuking my users and dataset which I recreated with the Unix permissions ;)

 

[BlazeStar]

so before the guide is out, can anyone point me somewhere I can lean how to use getfacl and setfacl ?

My permissions are completely messed up and I urgently need to rebuild them

I have several datasets, all of them are set up in FreeNAS GUI (9.2.1.9) with Windows type permissions.

I have one CIFS share for each dataset.

I've tried to set up the permissions using the Windows properties (security and stuff), this seems to be what is recommended when I browse the threads on the forum.

After doing so, I would get all kind of errors and then some users lost access to some shares, or even to some directories inside of shares, and all is messed up now.

getfacl on one of my CIFS shares gives me this:

Code:

# owner: ME
# group: MYGROUP
    user:USER1:rwxp-daARWc---:fd----:allow
user:USER2:rwxp-daARWc---:fd----:allow
    user:USER3:rwxp-daARWc---:fd----:allow
   user:USER4:rwxp-daARWc---:fd----:allow
            owner@:rwxpDdaARWcCo-:fd----:allow

so as you see...

1) there is no permission for the group ?!?

2) There are users who have specific rules

i want to recursively clean all that stuff

I've never used getfacl and setfacl... I'm only familiar with UNIX type permissions so I've been googling around but I can't find anything that will simply tell me how to do that step by step, cleanly, effectively:

For each dataset / CIFS share I want to set the permissions to 770, and specify a user and a group, recursively.


I'm just a unix fanboy who really liked the poetic beauty and the magnificent simplicity of CHMOD -R & CHOWN -R

Now I'm confused and I don't understand what is happening to me

PLEASE HELP!

 

[eduardoalvim]

Having this same problem right now. Need to rebuild my permissions, all of them set up in FreeNAS 8.3.0, but get the "Operation Not Permitted" when using chmod. Would like to be very usefull some kind of step by step instructions about fixing it. As BlazeStar above, I can understand chmod and chown commands, but I'm completely lost about ACLs...

 

[esamett]

N00b to N00b:

ACL and permissions are a non-trivial topic that the "experts" are working through. There are "unexpected results" that occur when using FreeNAS with non-unix systems. (search for comments on topic by cyberjock on this forum) Problems for users started to crop up last year when SAMBA (An open source application FreeNAS uses for communicating with Windows systems) was updated. While it may be possible to "fix the broken permissions" it is easier to avoid problemsaltogether:

1. start with a NEW (empty) Windows dataset, preferably within a new Unix volume. Follow available instructions. There is alot happening with permissions and ACLs behind the scenes.

2. Copy and paste your data from your old "problematic" dataset to the new dataset using Windows Explorer. This is very important.

3. Any changes to permissions for files within your new Windows dataset should be done through Windows Explorer. This is very important.

4. Once you verify that things are working properly then you can delete your old dataset/volume.

Cyberjock said last year that he was working on a permissions and ACL guide but that the topic was complicated and incompletely documented. For the timebeing I advise starting from scratch as I described above.

Good luck.

 

[CraftyClown]

N00b to N00b:

ACL and permissions are a non-trivial topic that the "experts" are working through. There are "unexpected results" that occur when using FreeNAS with non-unix systems. (search for comments on topic by cyberjock on this forum) Problems for users started to crop up last year when SAMBA (An open source application FreeNAS uses for communicating with Windows systems) was updated. While it may be possible to "fix the broken permissions" it is easier to avoid problemsaltogether:

1. start with a NEW (empty) Windows dataset, preferably within a new Unix volume. Follow available instructions. There is alot happening with permissions and ACLs behind the scenes.

2. Copy and paste your data from your old "problematic" dataset to the new dataset using Windows Explorer. This is very important.

3. Any changes to permissions for files within your new Windows dataset should be done through Windows Explorer. This is very important.

4. Once you verify that things are working properly then you can delete your old dataset/volume.

Cyberjock said last year that he was working on a permissions and ACL guide but that the topic was complicated and incompletely documented. For the timebeing I advise starting from scratch as I described above.

Good luck.

If only I had come across this thread a couple of months ago! I've been having endless Unix/windows permissions issues that just didn't make sense, but as a complete noob, I just presumed I was being a total idiot and failing to understand the basics. To be fair there probably was an element of that involved, but I'm now damn sure this has been partly to blame!

 

[CraftyClown]

Ok, so at this stage I'n not sure whether I need to be worried about the state my permissions have ended up in.

Despite all my volumes and datasets, once more being set to Unix permissions, if I ls -l my three pools I get the following:

[root@freenas /mnt]# ls -l
total 11
drwxrwxr-x+ 6 root wheel 6 Mar 7 12:42 Movies_and_Music
drwxrwxr-x+ 3 root wheel 3 Mar 6 23:34 Music
drwxrwxr-x+ 6 root wheel 6 Mar 10 23:06 TV
-rw-r--r-- 1 root wheel 5 Jan 31 03:19 md_size

am I correct in thinking that drwxrwxr-x+ signifies Windows ACL?

subsequent datasets within those pools exhibit the same problems and much like other posters, I am unable to change said permissions recursively via the gui or via the shell and chmod. I am also suddenly unable to SSH in to my Freenas box

Have I painted myself into a corner here? I've seen mention of setfacl to potentially fix the ACLs, however having had a quick look into it's usage, it seems a bit outside of my comfort zone right now. I'm starting to worry I might need to do a complete re-install :(


@cyberjock any progress on the permissions guide? I have a strange feeling it's going to become required reading around these parts, once released :)

 

[esamett]

Noob:

I was unsuccessful in my attempts at "fixing" permissions. I suspect that there is some undocumented quirkiness in the background. I am very satisfied with the "start from scratch and copy" method I described that I learned from the "wise ones."

good luck

 

[CraftyClown]

Thank you Esamett,

I did indeed use the method you suggested. I created a new sub dataset (UNIX) gave it a windows share and then proceeded to copy everything from the old sub dataset (containing files with a Windows ACL) over to my new share via a Windows box on my LAN.

Lo and behold, the Windows ACL was gone and my directories and files were once more rwxrwxrwx, sans the +

I'm still not sure whether I should be concerned by the fact my pools are stuck with the Windows ACL at a root directory level though. Could this cause me headaches in the future?

 

[David Dyer-Bennet]

I think perhaps this "no chmod" feature (which I don't understand and don't want) has broken rsyncd. I'm not aware of any way to tell rsync to turn permissions *into* ACLs, and when I tell rsync to copy permissions, it gets errors setting them that sound like the problem discussed in this thread.

More generally -- ACLs ruin everything. I would love to ban them completely from my network.

 

[ewhac]

My limited reading on the subject suggests that ACLs are a superset of RWX-style mode bits and, as such, recent-vintage filesystems internally use only ACLs, and dynamically translate back to mode bits. Imprecise translations get you the appended '+'.

However, this is only for POSIX-style ACLs. Windows ACLs are broadly similar, but different enough to cause headaches.

 

[David Dyer-Bennet]

And FreeBSD ZFS supports only NFSV4 ACLs, not POSIX (Sun's did confusing things supporting both, I believe). Windows is closer to NFSV4, in fact Windows is a subset of NFSV4.

Most important ACL command: setfacl -b

 

[anodos]

My limited reading on the subject suggests that ACLs are a superset of RWX-style mode bits and, as such, recent-vintage filesystems internally use only ACLs, and dynamically translate back to mode bits. Imprecise translations get you the appended '+'.

However, this is only for POSIX-style ACLs. Windows ACLs are broadly similar, but different enough to cause headaches.

It gets pretty complicated. There are several different permissions schemes that may be used on different operating systems, which I have listed below roughly in ascending order in terms of information stored.

• Traditional Unix mode bits (rwx, etc.)
• POSIX Draft ACLs (POSIX 1e ACLs)
• NFSv4 ACLS (like you see in ZFS)
• Windows ACLS
• RichACLs (NFSv4 ACLs as implemented in EXT4 / linux)

One key difference between the Windows ACL implementation and NFSv4 ACLs is that Windows does not have the special owner, group or everyone principals in ACEs. This does ultimately cause differences between the behavior of a samba server and a windows server, and makes "chmod" a potentially hazardous command in a samba context. That said, I believe the solaris version of chmod does properly respect and can set NFSv4 ACLs.

 

[David Dyer-Bennet]

One tiny change would fix most of my problems -- running as root should give you full access to all files and directories. If they hadn't messed that up, I could fix everything else.

 

[anodos]

One tiny change would fix most of my problems -- running as root should give you full access to all files and directories. If they hadn't messed that up, I could fix everything else.

Who messed what up? If you want to chmod something on a windows dataset as root type "zfs set aclmode=passthrough <pool>/<dataset>" then chmod / fubar samba to your heart's content. :D

 

[David Dyer-Bennet]

People designing ACLs messed up root access. With no benefits I can see.

 

[anodos]

People designing ACLs messed up root access. With no benefits I can see.

I don't see how root access is messed up. There are benefits to using ACLs even if they may not be useful in your particular use case. In the case of samba it allows a Unix server to behave in a way that is almost indistinguishable from a Windows server, which is a good thing.

 

[David Dyer-Bennet]

Root access used to be how you fixed things if the permissions got messed up. Now there appears to be no way to fix things if the permissions get messed up. I mean, you can probably eventually find a way to do it, with a lot of research and a few pages of notes, but there isn't a simple technique that just works.

And I've never seen a windows shop ever use ACLs, and everywhere I've worked since 1996 has had windows in the mix.

 

[anodos]

Root access used to be how you fixed things if the permissions got messed up. Now there appears to be no way to fix things if the permissions get messed up. I mean, you can probably eventually find a way to do it, with a lot of research and a few pages of notes, but there isn't a simple technique that just works.

And I've never seen a windows shop ever use ACLs, and everywhere I've worked since 1996 has had windows in the mix.

Windows uses ACLs. You can not use modern windows without using ACLs. They are a part of NTFS. You can use root to modify ACLs. There is a tool. It's called "setfacl". If you don't like that, there is another tool called "winacl". If you don't like that, there's another tool called "smbcacls". Pretty much the only tool that doesn't work is "chmod", which in solaris can be used to modify ACLs, but doesn't 'work' in certain situations in the Linux / BSD world. The problem with induction from a small sample set is that the results are often wrong.

 

[David Dyer-Bennet]

However, "cp -a" doesn't work any more, and rsync doesn't work any more. This is far to high a cost for a feature of little known utility.