blob: f111a4c23be033936f7298f8821031c6d49c3920 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
|
<samba:parameter name="ea support"
context="S"
type="boolean"
xmlns:samba="http://www.samba.org/samba/DTD/samba-doc">
<description>
<para>This boolean parameter controls whether <citerefentry><refentrytitle>smbd</refentrytitle>
<manvolnum>8</manvolnum></citerefentry> will allow clients to attempt to access extended
attributes on a share. In order to enable this parameter on a setup with default VFS modules:
</para>
<itemizedlist>
<listitem><para>Samba must have been built with extended attributes support.
</para></listitem>
<listitem><para>The underlying filesystem exposed by the share must support extended
attributes (e.g. the getfattr<manvolnum>1</manvolnum> / setfattr<manvolnum>1</manvolnum>
utilities must work).
</para></listitem>
<listitem><para>Access to extended user attributes must be allowed by the underlying
filesystem (e.g. when mounted with a system-dependent option like user_xattr on Linux).
</para></listitem>
</itemizedlist>
<para>
This option exposes the "user" attribute namespace from the underlying filesystem to
clients. In order to match Windows conventions, the namespace prefix ("user.") is
stripped from the attribute name on the client side. The handling of further attribute
namespaces (like "security", "system", or "trusted") is not affected by this option.
</para>
<para>
Note that the SMB protocol allows setting attributes whose value is 64K bytes long,
and that on NTFS, the maximum storage space for extended attributes per file is 64K.
On some filesystem the limits may be lower. Filesystems with too limited EA
space may experience unexpected weird effects.
The default has changed to yes in Samba release 4.9.0 and above to allow better Windows
fileserver compatibility in a default install.
</para>
</description>
<value type="default">yes</value>
</samba:parameter>
|
