15.09.2022 13:17, Michael Tokarev wrote:
...
Now, I don't know which permissions/ownership you files *had* before you
changed them. Please
note how this directory is being created:
install -d -m 1770 -g sambashare /var/lib/samba/usershares
The "1" "sticky" bit tells the kernel to use the same group for all
subdirectories and files
created within. So you should not need to change the group ownership in the
first place. If
you had to, it means this sticky bit hasn't been there in your case. Which, in
turn, means
some local modification you did, probably.
This is ofc incorrect, sticky bit has nothing to do with the group
ownership.
Now, the files *within* /var/lib/samba/usershares/ dir should belong to whatever
user/group who created them, definitely not to root:sambashare. More, if these
belong to root, usershare owner only (default yes) will prevent
removing/modifying
shares by using `net usershare' command. Only this directory itself should
belong
to group sambashare.
And your user definitely should have write access to this directory in order to
*add*
share definitions by using `net usershare add' etc commands. Not for *using*
the
already defined shares but to *add* them.
Either way, after you actually changed the ownership/permission bits, it's
impossible to
see what the actual problem was.
I still don't know which ownership/permissions you did have. I tried to
replicate
this issue, - I can trigger this warning in the smbd logfile:
[2022/09/15 14:06:28.521611, 0]
../../source3/param/loadparm.c:3454(process_usershare_file)
process_usershare_file: stat of /var/lib/samba/usershares/data failed.
Permission denied
but there's no crashes, it is just a warning.
So it must be something specific to your configuration.
/mjt
