Hello,
On Sun 15-01-23 23:56:21, Patrik Schindler wrote:
> sorry for contacting you directly, but I struggle to find relevant
> information on this topic.
This is best discussed on ext4 development mailing list (added to CC).
> In this web page is documented that "noacl" for ext4 is deprecated.
>
> https://patchwork.ozlabs.org/project/linux-ext4/patch/[email protected]/
>
> Do you have some background information at hand why noacl is deprecated,
> and how to get the functionality of noacl after this change?
Yes, these options were deprecated for a long time (10 years) and now they are
removed since nobody complained. The reasoning is in commit f70486055ee
("ext4: try to deprecate noacl and noxattr_user mount options"):
No other file system allows ACL's and extended attributes to be
enabled or disabled via a mount option. So let's try to deprecate
these options from ext4.
-
And it makes sense to me. It looks a bit strange and dangerous to disable
(part of) permission checks for the files. What usecase did you have for
it?
Honza
--
Jan Kara <[email protected]>
SUSE Labs, CR
Hello Jan,
thanks for your kind response.
Am 16.01.2023 um 11:42 schrieb Jan Kara <[email protected]>:
> On Sun 15-01-23 23:56:21, Patrik Schindler wrote:
>> sorry for contacting you directly, but I struggle to find relevant
>> information on this topic.
>
> This is best discussed on ext4 development mailing list (added to CC).
Am I required to join that list?
>> In this web page is documented that "noacl" for ext4 is deprecated.
>>
>> https://patchwork.ozlabs.org/project/linux-ext4/patch/[email protected]/
>>
>> Do you have some background information at hand why noacl is deprecated,
>> and how to get the functionality of noacl after this change?
>
> Yes, these options were deprecated for a long time (10 years) and now they are removed since nobody complained. The reasoning is in commit f70486055ee ("ext4: try to deprecate noacl and noxattr_user mount options"):
>
> No other file system allows ACL's and extended attributes to be enabled or disabled via a mount option. So let's try to deprecate these options from ext4.
Understood.
> And it makes sense to me. It looks a bit strange and dangerous to disable (part of) permission checks for the files. What usecase did you have for it?
I'm using Debian Linux 11.
When copy Files from my Mac via Samba to ext4 volumes, ACLs get added. (Much) earlier, this wasn't the case, and just UNIX permissions were in effect. For me, UNIX permissions are totally sufficient, and I can easily see what's going on with ls -l. For ACLs, I need to individually fiddle with get/setfacl.
This feels cumbersome to me and gives me a sense not having immediate control over access rights. Thus I'd like to find a way to get the previous behavior back. Ideally without recompiling samba to remove ACL support, as outlined here: https://serverfault.com/questions/828977/how-can-i-stop-samba-from-writing-extended-acls
For a very long time I had noacl in my fstab but with the update to Debian 11, I saw the message about the deprecation. Not sure when I observed ACLs being actually written by Samba, though.
In addition, even newer Google hits almost entirely state "noacl in fstab to suppress ACLs for ext4", so I'm probably not the only one trying to disable them and people largely failed to understand that noacl has no effect anymore.
Thanks!
:wq! PoC
Hello Patrik!
On Mon 16-01-23 13:25:07, Patrik Schindler wrote:
> Am 16.01.2023 um 11:42 schrieb Jan Kara <[email protected]>:
>
> > On Sun 15-01-23 23:56:21, Patrik Schindler wrote:
> >> sorry for contacting you directly, but I struggle to find relevant
> >> information on this topic.
> >
> > This is best discussed on ext4 development mailing list (added to CC).
>
> Am I required to join that list?
No, the list is open so anyone can post to it.
> >> In this web page is documented that "noacl" for ext4 is deprecated.
> >>
> >> https://patchwork.ozlabs.org/project/linux-ext4/patch/[email protected]/
> >>
> >> Do you have some background information at hand why noacl is deprecated,
> >> and how to get the functionality of noacl after this change?
> >
> > Yes, these options were deprecated for a long time (10 years) and now they are removed since nobody complained. The reasoning is in commit f70486055ee ("ext4: try to deprecate noacl and noxattr_user mount options"):
> >
> > No other file system allows ACL's and extended attributes to be enabled
> > or disabled via a mount option. So let's try to deprecate these
> > options from ext4.
>
> Understood.
>
> > And it makes sense to me. It looks a bit strange and dangerous to
> > disable (part of) permission checks for the files. What usecase did you
> > have for it?
>
> I'm using Debian Linux 11.
>
> When copy Files from my Mac via Samba to ext4 volumes, ACLs get added.
> (Much) earlier, this wasn't the case, and just UNIX permissions were in
> effect. For me, UNIX permissions are totally sufficient, and I can easily
> see what's going on with ls -l. For ACLs, I need to individually fiddle
> with get/setfacl.
>
> This feels cumbersome to me and gives me a sense not having immediate
> control over access rights. Thus I'd like to find a way to get the
> previous behavior back. Ideally without recompiling samba to remove ACL
> support, as outlined here:
> https://serverfault.com/questions/828977/how-can-i-stop-samba-from-writing-extended-acls
>
> For a very long time I had noacl in my fstab but with the update to
> Debian 11, I saw the message about the deprecation. Not sure when I
> observed ACLs being actually written by Samba, though.
>
> In addition, even newer Google hits almost entirely state "noacl in fstab
> to suppress ACLs for ext4", so I'm probably not the only one trying to
> disable them and people largely failed to understand that noacl has no
> effect anymore.
I understand the wish for more overview over file permissions but this
seems like a bit awkward way to reach it? It rather seems like a lack of
control in the smbget(1) tool (or whatever you are using for the copying)?
Adding an option there to not copy permissions from the server would look
like a very logical thing to do (similarly as cp(1) has these options)...
Would that work?
Honza
--
Jan Kara <[email protected]>
SUSE Labs, CR
Hello Jan,
Am 17.01.2023 um 11:45 schrieb Jan Kara <[email protected]>:
> I understand the wish for more overview over file permissions but this seems like a bit awkward way to reach it?
This might be a matter of taste.
> It rather seems like a lack of control in the smbget(1) tool (or whatever you are using for the copying)?
Im using my Mac with macOS. I mount a samba share and use the Finder to copy files by drag & drop.
> Adding an option there to not copy permissions from the server would look like a very logical thing to do (similarly as cp(1) has these options)... Would that work?
In this case: No, wouldn't work.
But your response made me wade through smb.conf(5) again, specifically searching for "acl" and found:
nt acl support = no
to be the adequate solution after trying. With that, copying files doesn't add ACLs anymore.
Sorry for bugging you and all the list members. Thank you for helping me think. :-)
:wq! PoC