Hi,
I have configured vfs_streams_depot to support some NTFS metadata. The
metadata files are being created but permissions are not inherited from
their parent objects. Only a user who created the metadata has full access
to it.
For example, we have one file object "file1" and few users having full
access to it. If one user creates metadata information all other users
cannot read nor write metadata.
Tried to configure ACL (everybody read-write access) on the
<streams_depot:directory> but the actual permissions are still not
inherited.
The type of metadata being used is MAC tags.
Running samba-4.2.10-7.el7_2.x86_64 on CentOS 7.2.1511.
Stock kernel 3.10.0-327.28.2.el7.x86_64
Samba is running as AD member. The shares are on ext4 file system.
Config:
[global]
workgroup = COMPANY
netbios name = test04
realm = COMPANY.COM
security = ads
log file = /var/log/samba/log.%m
max log size = 5000
log level = 2
load printers = no
printing = bsd
printcap name = /dev/null
store dos attributes = yes
map hidden = no
map system = no
map archive = no
map readonly = no
map acl inherit = yes
acl group control = yes
inherit acls = yes
inherit permissions = yes
usershare owner only = no
map untrusted to domain = yes
allow insecure wide links = yes
wide links = yes
winbind separator = /
winbind use default domain = no
winbind expand groups = 10
winbind refresh tickets = yes
winbind max domain connections = 10
kerberos method = system keytab
create krb5 conf = no
allow nt4 crypto = yes
server signing = auto
idmap config * : backend = tdb
idmap config * : range = 20000-99999
idmap config COMPANY : default = yes
idmap config COMPANY : backend = rid
idmap config COMPANY : range = 200000-999999
vfs objects = acl_xattr streams_depot
streams_depot:directory = /smb/streams
streams_depot:delete_lost = yes
[tmp]
path = /smb/tmp
public = no
writable = yes
browseable = yes
Eventually, I was able to fix it using masks. create mask = 0774 directory mask = 0775 On Thu, Aug 11, 2016 at 2:15 PM, akan tortz <manas.marat at gmail.com> wrote:> Hi, > > I have configured vfs_streams_depot to support some NTFS metadata. The > metadata files are being created but permissions are not inherited from > their parent objects. Only a user who created the metadata has full access > to it. > > For example, we have one file object "file1" and few users having full > access to it. If one user creates metadata information all other users > cannot read nor write metadata. > > Tried to configure ACL (everybody read-write access) on the > <streams_depot:directory> but the actual permissions are still not > inherited. > > The type of metadata being used is MAC tags. > > Running samba-4.2.10-7.el7_2.x86_64 on CentOS 7.2.1511. > Stock kernel 3.10.0-327.28.2.el7.x86_64 > > Samba is running as AD member. The shares are on ext4 file system. > > Config: > > [global] > workgroup = COMPANY > netbios name = test04 > realm = COMPANY.COM > security = ads > > log file = /var/log/samba/log.%m > max log size = 5000 > log level = 2 > > load printers = no > printing = bsd > printcap name = /dev/null > > store dos attributes = yes > map hidden = no > map system = no > map archive = no > map readonly = no > map acl inherit = yes > acl group control = yes > inherit acls = yes > inherit permissions = yes > usershare owner only = no > map untrusted to domain = yes > allow insecure wide links = yes > wide links = yes > > winbind separator = / > winbind use default domain = no > winbind expand groups = 10 > winbind refresh tickets = yes > winbind max domain connections = 10 > kerberos method = system keytab > create krb5 conf = no > allow nt4 crypto = yes > server signing = auto > > idmap config * : backend = tdb > idmap config * : range = 20000-99999 > idmap config COMPANY : default = yes > idmap config COMPANY : backend = rid > idmap config COMPANY : range = 200000-999999 > > vfs objects = acl_xattr streams_depot > streams_depot:directory = /smb/streams > streams_depot:delete_lost = yes > > [tmp] > path = /smb/tmp > public = no > writable = yes > browseable = yes > > >
On Fri, Aug 12, 2016 at 02:02:31PM -0400, akan tortz via samba wrote:> Eventually, I was able to fix it using masks. > > create mask = 0774 > directory mask = 0775Thanks for updating the list with the answer. Much appreciated !