Can't chmod files - Operation not permitted

[anodos]

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.

rsync works. Some switches don't work as intended. Modify your rsync command accordingly. 'cp -a' doesn't work because it's trying to change mode bits. Specify the attributes that you want to preserve.

Note that this only applies to "windows" datasets, which are for samba shares. Presumably you want the files you copy or rsync to your samba share to be accessible by your samba users (and not break your permissions). This means that you do not want to preserve the mode bits from the source directory. You want the copied files to inherit the ACLs from the parent directory at their destination.

Note that samba on FreeBSD lacks the ability to use kernel oplocks (like samba on Linux does), this means that you really should avoid going behind samba's back (especially on a heavily-used samba server). This means that your 'cp' and 'rsync' process may not see when a user has a file open (because samba holds oplock info in locking.tdb), which can result in data corruption. So disabling samba's oplocks is probably also a good idea in the use-case you are mentioning.

Anyway, I use ACLs and find them very useful. Don't be so narrow-minded. :p

 

[David Dyer-Bennet]

I frequently find I can't access files via Samba because of ACLs; the solution always seems to be (so far) to get rid of the ACLs, and re-set the permissions to something sane.

 

[anodos]

I frequently find I can't access files via Samba because of ACLs; the solution always seems to be (so far) to get rid of the ACLs, and re-set the permissions to something sane.

For information regarding how to get rysnc to work (i.e. adding switch "--no-p") see here - https://bugs.freenas.org/issues/14434
For information regarding the decision to only support "windows permissions type" on samba shares see here - https://bugs.freenas.org/issues/11390

That's just a cursory search of the bugtracker. The problem you describe here is typical when a user has either (1) set permissions type to "unix" on a samba share or (2) is manipulating permissions on a samba share from the CLI [note that is not an exclusive or].

My experience is that the best way configure permissions on a samba share is to utilize non-trivial ACLs for users and groups that need access. This means I leave the dataset owned by root:wheel. I remove the @ everyone ACE, Then I add an ACE on the root of the share to grant full control to "domain admins" and add additional ACEs for groups that need access to the share. This avoids relying on the @owner, @group,@ everyone trivial ACEs. Windows behaves better with non-trivial ACEs (the NFSv4 trivial ACEs are an area where NFSv4 ACLs differ from Windows ACLs).

When done right, ACLs are a fire-and-forget thing. Figure out how permissions should be configured, set them at the root of the share, then move on to other things. I've been running this way in a busy multi-user environment for a few years now without any issues (I don't think I've even touched permissions for over a year).

 

[David Dyer-Bennet]

I want to share files between Windows, Mac, and Unix boxes, including working directly on the files directly on the server. And setting up the permissions on an entire sub-tree and leaving them permanently that way is completely useless; I need to change who can access certain projects as the people involved change. Unix schemes handle this simply and easily -- just put people in the right groups. No description I've yet heard of ACLs comes anywhere close to doing what's necessary for those cases I encounter every week. They're great for weird exceptions, that Unix doesn't handle very well; but I find those nearly nonexistent in the real world.

 

[anodos]

I want to share files between Windows, Mac, and Unix boxes, including working directly on the files directly on the server. And setting up the permissions on an entire sub-tree and leaving them permanently that way is completely useless; I need to change who can access certain projects as the people involved change. Unix schemes handle this simply and easily -- just put people in the right groups. No description I've yet heard of ACLs comes anywhere close to doing what's necessary for those cases I encounter every week. They're great for weird exceptions, that Unix doesn't handle very well; but I find those nearly nonexistent in the real world.

I see them all the time in the real world. Especially with crufty windows file servers that have been around for a long time

\\windowz\ImportantStuff
\\windowz\ImportantStuff\secretz

Domain\Engineers needs read+write access to "ImportantStuff"
Domain\Marketing needs read-only access to "ImportantStuff" but should have no access to "ImportantStuff\Secretz"
Domain\Management needs read-only access to "ImportantStuff"
Domain\Interns need read-only access to "ImportantStuff" but should have no access to "ImportantStuff\Secretz"

You need to replicate this behavior without touching a DC (because that will potentially affect access control for other servers on the network) and without affecting anyone's workflow.

On a side-note, I feel that samba is becoming increasingly a service that does not behave well with other methods of accessing data. It stores file metadata in ways that are not accessible to other applications (vfs_streams_xattr, vfs_streams_depot, vfs_fruit, etc.) making it much more hazardous to manipulate data from the CLI or other filesharing protocols. This is especially true if you're using Macs. For example, if you copy a file from your mac to a samba server, samba will write data (which might be important to the file's integrity) to what it considers to be an alternate datastream (ADS). Samba places this data in a special folder (in the case of streams depot) or . Then you use sftp to download the file from the samba server. Whoops, that data is gone. Sometimes losing the information in the ADS is unimportant. Sometimes you lose file integrity. It just depends on the application creating the file and the purpose of the ADS.

 

[David Dyer-Bennet]

Is your Samba environment based on AD? Because mine isn't, and that may be part of the difference. If you're using AD groups to manage access, that would explain a lot of our different approaches. I need to use Unix users or groups, because that's all there really is.

 

[anodos]

Is your Samba environment based on AD? Because mine isn't, and that may be part of the difference. If you're using AD groups to manage access, that would explain a lot of our different approaches. I need to use Unix users or groups, because that's all there really is.

Well, yes I use AD in a professional environment. I'm using it as an example because it is easy to see why NFSv4 ACLs are desirable from the samba standpoint without going into all the nitty-gritty details. If you want to read up more on it, see Jeremy Allison's and Steve French's responses to the discussion of code commit to RichACLS here: https://lkml.org/lkml/2016/3/11/575

 

[{HD}]

Is there a way to recursively remove ACLs and start fresh without copying all of my data to a new dataset. I am currently having this issue and it is driving me crazy. A reset permissions button should exist in the WebUI.

 

[esamett]

There is a way in the permissions screen. IIRC if you set the permissions as you wish then set "recursive" option. The manual should be your friend.

 

[anodos]

There is a way in the permissions screen. IIRC if you set the permissions as you wish then set "recursive" option. The manual should be your friend.

There is a reset button called "apply default permissions" in your share config. If you are switching to Unix permissions type, change the type, then apply new permissions recursively through the webui. If that doesn't work, try using the following command find /mnt/<pool>/<dataset> -exec setfacl -b {} \; Populate <pool>/<dataset> with the path to your share.

 

[ric]

Same exact error here when I use "chmod" to change permission of the /media dir. Please see attached screenshot photo.

Also, same thing happened when using setfacl. See below.

root@owncloud_1:/ # setfacl -m user::rwx,group::rwx,other::--- /media/
setfacl: media/: branding mismatch; existing ACL is NFSv4, entry to be merged is POSIX.1e

 

[anodos]

Same exact error here when I use "chmod" to change permission of the /media dir. Please see attached screenshot photo.

Also, same thing happened when using setfacl. See below.

root@owncloud_1:/ # setfacl -m user::rwx,group::rwx,other::--- /media/
setfacl: media/: branding mismatch; existing ACL is NFSv4, entry to be merged is POSIX.1e

Your setfacl command is wrong. The syntax for NFSv4 ACLs is setfacl -m owner@:full_set:fd:allow, group@:full_set:fd:allow /media/, but this doesn't recurse. It looks like owncloud wants you to get rid of the "everyone" ace. You can do this through the following command find /media -exec setfacl -x everyone@::allow {} ;\

 

[ric]

Did run the command as follows but nothings happened. Should I replace "everyone" to something?

root@owncloud_2:/media # find /media -exec setfacl -x everyone@::allow {} ;\
?

 

[anodos]

Did run the command as follows but nothings happened. Should I replace "everyone" to something?

root@owncloud_2:/media # find /media -exec setfacl -x everyone@::allow {} ;\
?

No. I replied to your other forum post with instructions.