Can't chmod files - Operation not permitted

[demon_devil]

Running FreeNAS-9.2.1.6-RELEASE-x64


My ssh key casually stopped working and is now being rejected. Went on with a verbose passworded ssh, upon password connection I received a log detailing a permission error with my key file.

Indeed, yes indeed.

.ssh wasn't 700 but 771
and authorized_key wasn't 600 but 771

This is very strange considering that my dataset and User home directory were assigned permissions 770 and 700 from the GUI respectively...

Anyways, I went on to chmod that and, well well, much to my surprise the Operation is not permitted.

I tried as root, as the user, as the user with sudo, nothing!


The key used to work until I switch the dataset to Microsoft ACL. Didn't know why it would do that, but now I read that maybe the MC permissions were not compatible. When this happened, I deleted the User and his dataset. Then recreated them (with the same name) but with the UNIX share type and this is about the same time I noticed that dataset and home directory permissions are not being set properly. In fact, even the log said that it couldn't chmod the directory and files present in the dataset that are automatically created. As I mentioned earlier, I can't chmod manually either.

Edit: Forgot to mention that the dataset ownership is set to the User account and nogroup.

 

[cyberjock]

Yes, this is a new feature of 9.2.1.6+. chmod is not appropriate for changing permissions if Windows ACLs are used for the given file(s)/folder(s). In your case the operation wasn't permitted because if it had succeeded then your Windows ACLs would have been corrupted. This is one of a few new "features" to help prevent people from stabbing themselves on the foot with the wrong command. Try using setfacl instead of chmod. ;)

 

[demon_devil]

Thanks for the reply. It does explain why I couldn't chmod initially.
However, the dataset was destroyed, recreated as a UNIX share type and the problem persisted (I recreated, destroyed and recreated a bunch of time under the same name).

The problem I'm describing in this thread happened yesterday. This morning, I rebuilt the LDAP Cache (under Settings -> Advanced). Then I tried to recreate my user and dataset.

My key is now being accepted and the permissions are correct. I don't know if the rebuilding had something to do about it, or the server did something in the night.

I'm hoping that this thread documenting my problem will help a future fellow.

 

[ewhac]

Yes, this is a new feature of 9.2.1.6+. chmod is not appropriate for changing permissions if Windows ACLs are used for the given file(s)/folder(s). In your case the operation wasn't permitted because if it had succeeded then your Windows ACLs would have been corrupted. This is one of a few new "features" to help prevent people from stabbing themselves on the foot with the wrong command. Try using setfacl instead of chmod. ;)

Glad I read it here first, rather than finding it out the hard way.

However, I am not prepared to cut Windows any slack on any point whatsoever. As far as I'm concerned, mine is a Linux/UNIX network, and Windows just has to cope. If Windows' special snowflaky features cause any headaches for me on the Linux side, then Windows gets punched in the gut until it falls into line. So: Any suggestions on how to setup CIFS shares such that Windows just has to make do with rwxrwxrwx?

 

[cyberjock]

Honestly, I don't think you can. This is one of the things that I've been talking with one of the iX devs about. Samba 4 works with NFSv4 permissions and uses the ACLs. This is *part* of the reason why so many people are having problems with Windows permissions on FreeNAS. I'm not aware of any way to make Samba4 use Unix permissions as a substitute for Windows ACLs since Windows has more than just read,write, execute. In fact NFSv4 has more permissions options than Windows has, so Samba does some conversion internally.

Unfortunately, your limitations are almost certainly Samba related and there is almost no documentation on how Samba works. Even iX's developers have had to learn by asking Samba developers directly and trial-by-fire.

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

If you do figure out how to get it to work I'd definitely like to hear about it. I'd love to add that kind of info to a guide I'm writing on file permissions for Windows.

 

[AleQQ]

I am writing a guide on how to handle permissions properly in FreeNAS

You're a god O.O

If it's not too much trouble, can you PM me a link to it when you're done?

 

[cyberjock]

Actually, it'll be a forum announcement most likely and will probably generate much fanfare. ;)

 

[AleQQ]

I will await the parade with pompoms in-hand! ;)

 

[ewhac]

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

Other than their unfamiliarity, I don't necessarily have anything against ACLs qua ACLs. I just have very firm ideas about Windows' engineering competence, quality, security, and consequently the role it should have in defining my network requirements and administration (i.e. none, none, none, and none). Every so often I go poking around for an introduction to Samba setup, and far too many of them eventually arrive at Step #N which starts, "Now go to your Windows machine, right-click on the share volume, select 'Manage Share...,' and..."

No. No, I will not. The whole point of using Samba is to make Windows' presence in your LAN irrelevant to network planning and administration. The moment you require Windows-hosted tools to do network or share admin, you've failed.

I, too, look forward to your file permissions guide.

 

[esamett]

I posted my problem on Noob section

 

[Rogla]

Despite any deeper knowledge about NFSv4 ACL's, I managed to fix this.

Simply use command 'getfacl file' to list the ACL's.
To delete the ACL, copy the ACL string (everyone and group) and paste it into command 'setfacl -x ACL file'

Example:

I got this problem after toggeling the "Apply Default Permissions" option on the CIFS share.
The directory is a dataset with unix only permission, didn't think that the ACL would be affected ther by the "Apply Default Permissions". Now I know.

 

[esamett]

NOOB:
1. Can you explain how/why removing (-x) the group and everyone permissions helps with your problem? This topic is difficult wrap my mind around.

2. The setfacl "-x" flag is not included in FreeBSD documentation:
http://www.freebsd.org/cgi/man.cgi?query=setfacl&manpath=SunOS+5.10
but is part of linux documentation:
http://linux.die.net/man/1/setfacl

3. +1 for the efforts by Ms. Peach and iX to facilitate our using Windows in the FreeNAS world.

 

[Rogla]

Sure you have read the thread from the begining?
If you ask politely, I can remove my post, no problem..

1) To be able to run ssh, permision 775 is not allowed on the .ssh directory and containing config files.
The "Apply Default Permissions" option changed to 775 and disabled the chmod command.
It was not posible to chmod back to 600 or 700. No working ssh.
The only way to get ssh to work again was to remove everyone and group permisions via removing ACL resulting in 700 chmod permision.

2) If you have tried by yourself to use the FreeBSD ACL's on FreeNAS, you should have seen an error message something like "wrong ACL format, NFSv4 format should be used".
I briefely looked at the examples here https://wiki.freebsd.org/NFSv4_ACLs . Then I understood what to do.

3) Agree as long it doesn't render the system unsuable....
Edit: By the way, the dataset with the ssh user is in Permision Type = UNIX, not Windows / Mac ACL, so it should not have been changed by FreeNAS in the first place.

Anyway, I got my ssh back to life again.

 

[ericvr]

Hi guys, I'm new to this forum (this is my first post) and as I'm seeing the same issue as the OP I just wanted to let you guys know about it, to see if this is actually a bug and for future reference.

First of, thanks for all the manuals and posts about different aspects of Freenas, they're very helpful!
I'm running freenas 9.2.1.8-RELEASE-x86 on a ASROCK C2550 board with 16GB of ECC RAM; 4x2TB in encrypted RAIDZ2 and gold PSU with APC UPS.

I created a few datasets on my raidz2 pool with 'type of ACL' set to 'windows' as I was only going to use CIFS on these shares (from windows and MAC stations). Later I realized this was the wrong reason to choose for this type of ACL, so I changed it to 'UNIX/MAC' (as also recommended in the freenas 9.1.2 user guide). The issue I'm facing now is that I can't chmod any of these datasets (not as sudo and not as the owner). I get the message 'operation not permitted'. This also happens from the GUI (I check the checkbox and save it, when I re-open it, the checkbox is unchecked). The OP stated that the problem disappeared after rebuilding the LDAP cache. I'm not using LDAP, so not sure if this would help me (will see if I can do this tonight). Is this a bug or am I missing something?

Thanks and best regards,
Eric

 

[cyberjock]

Yes, and that error is by design. chmod/chown/chgrp is not appropriate for ACLs. If you want to edit ACLs the proper answer is with getfacl and setfacl.

 

[ericvr]

Thanks for the quick reply cyberjock, clear.
What puzzles me is why the changes of the permission checkboxes in the GUI are ignored, or why these checkboxes even exist if they just ignore the input?

 

[cyberjock]

It should be true only for datasets that are set to Windows datasets.

Not sure what you mean when you say changes to the GUI permission checkbox are ignored. If you are talking about changing the dataset type, that is not supported in the WebGUI. If you are talking about the checkboxes in the WebGUI for setting read/write/execute bits for files (in effect Unix-style permissions) for WIndows datasets, those are also not supported in the WebGUI.

If you want Windows datasets (and you basically do for CIFS shares), you are going to be setting permissions from within windows after you get access to the dataset/share. That's the best way to get things done. The second best (and only other way) is via CLI with getfacl and setfacl.

 

[ericvr]

I've set set my dataset to Unix/Mac dataset.
When I make a change to one of the permission checkboxes (e.g. remove group writable) and save and reopen it, the change to the checkbox is gone (e.g. the group writeable box is still checked).

Why I think it might be a bug: I've done almost the same thing as the OP: The dataset was created as Windows and was later changed to UNIX/MAC. The OP created the dataset as Windows, deleted it and recreated it as UNIX/MAC and had the same issue as I'm having.

You state 'If you are talking about changing the dataset type, that is not supported in the WebGUI'.
It is possible in the GUI to change the 'Type of ACL' checkbox from Windows back to UNIX/MAC (as I did). Is this what is causing the strange behavior of the checkboxes (maybe the 'Type of ACL' is still set to Windows, but the GUI allows the 'Type of ACL' to be changed and the permission checkboxes buttons to become available again (not greyed out)?

 

[cyberjock]

You state 'If you are talking about changing the dataset type, that is not supported in the WebGUI'.
It is possible in the GUI to change the 'Type of ACL' checkbox from Windows back to UNIX/MAC (as I did). Is this what is causing the strange behavior of the checkboxes (maybe the 'Type of ACL' is still set to Windows, but the GUI allows the 'Type of ACL' to be changed and the permission checkboxes buttons to become available again (not greyed out)?

Not a clue. It didn't work for me last week when I tried it and the dev's answer was "that was unsupported". In fact, on mine you could give the appearance of changing it, but if you saved the "changes" and went back it hadn't actually changed.

 

[ericvr]

Ok, I did a quick test
1) Create a Volume with windows as share type
Share is created with rwxrwxr-x+ permission (ACL type)
2) Edit permissions from the GUI and change ACL type from Windows to UNIX
The Mode is no longer greyed out and checkboxes can be changed (read write etc)
ls on the dataset still shows rwxrwxr-x+ permissions, so still ACL type
3) Change one of the Mode checkboxes (I disabled group write), saved the changes and then again opened the Edit Permissions window
The checkbox is still checked and ls -l still shows the group has write permissions

So I guess you are right about the not being able to change the share type after creation of a dataset. The only strange thing is that with 'Edit Permissions' it is possible to change the checkbox from windows to unix and unlocking the permission options while these options will be ignored and permissions are treated as if this is a Windows type share (as set during creation).