samba - Jan 2024 - Samba file server share sets Windows Hidden attribute

I'm having a very odd problem. I have a domain member running Samba 4.18.9,
just
installed last weekend. It is a file server for the office who use Windows 10
and have a "drive" mapped to this host.

When users scan/append to existing PDF files on this mapped drive, they
disappear. Viewed on Windows, the H (hidden attribute) gets set. The user can
scan a new file to their mapped drive and it is visible. The user can
alternatively scan/append/save this modified file to their Desktop, then copy it
back (overwrite) it on the Samba share and it is visible.

Here's the odd thing, scan/appending to their Desktop works, but the Desktop
is
also a Samba share on another host, the DC! Same Samba version.

The smb.conf on the domain member (where the problem is):

=========================[global]
        max log size = 10000 
        realm = HPRS.LOCAL
        security = ADS
        server role = member server
        server string = HPRS NAS server
        template homedir = /home/%U
        template shell = /bin/bash 
        workgroup = HPRS
        idmap config hprs : range = 10000-999999
        idmap config hprs : backend = rid
        idmap config * : range = 3000-7999
        idmap config * : backend = tdb
        
vfs objects = acl_xattr
map acl inherit = yes  

load printers = no
printing = bsd
printcap name = /dev/null
disable spoolss = yes

usershare allow guests = Yes
usershare max shares = 10   

[public]
comment = OHPRS main file and document repository
path = /mnt/RAID/public
hide files = /Outlook/outlook/~*/

readonly = no
locking = yes
public = yes
printable = no
create mask = 0660
force user = user
force group = group
force create mode = 0660
directory mask = 2771
==========================
Other than the new 'vfs objects = acl_xattr' and 'map acl inherit =
yes', the
stuff in [public] is unchanged from before the Samba upgrade. In addition to
setting the Windows 'H' attribute on appended scanned PDF, new files of
any kind
(.pdf, .docx, ...) are create with permission 0771, not 0660, as prescribed in
the smb.conf.

The smb.conf on the DC defining the Desktop is:

========================[Users]
    path = /redirectedFolders/Users
    comment = user folders for redirection
    read only = No
=======================
In addition, the \\mail.hprs.local\Users has:
CREATOR OWNER:Full control:Subfolders and files only
Domain Admins:Full control:This folder, subfolders and files
Authenticated Users:Traverse Folder/Execute file,List folder/read data,Read
Attributes, Create folders/append data:This folder only
SYSTEM:Full Control:This folder, subfolders and files

In summary, users scanning/appending to PDF files on domain member share:
[public] end up with the files set to Windows attribute Hidden. The Linux
attributes are set to 0771, not 0660 as prescribed in the smb.conf.

Users scanning/appending to PDF files on their Desktop on domain controller
share: [Users] end up with the file NOT hidden, and the Linux permissions 
set to 0770.

Creating new files of any type have no problem with the hidden attribute.

Scanning/appending personnel files is the main task of employees at this
organization, so this is really a problem!

Why is this happening and how do I fix it?

Thanks --Mark

On Fri Jan 26 15:14:48 2024 Mark Foley via samba <samba at
lists.samba.org> wrote:
>
> I'm having a very odd problem. I have a domain member running Samba
4.18.9, just
> installed last weekend. It is a file server for the office who use Windows
10
> and have a "drive" mapped to this host.
>
> When users scan/append to existing PDF files on this mapped drive, they
> disappear. Viewed on Windows, the H (hidden attribute) gets set. The user
can
> scan a new file to their mapped drive and it is visible. The user can
> alternatively scan/append/save this modified file to their Desktop, then
copy it
> back (overwrite) it on the Samba share and it is visible.
>
> <snip>
Thanks to a response from a poster on LinuxQuestions.org I found I had to set
the "store dos attributes = on" attibute in smb.conf. I've already
expressed my
feelings about changing defaults which affect production programs, and this is
another example. Our users and I spent a week trying to figure out what was
going on.

The LQ poster said that the default had been changed in version 4.9.0+. I then
searched all the release notes from my previous 4.6.16 version until I did find
this change noted in the release notes for 4.9.0.

I'm sure this default change broke more systems that it fixed as this is a
major
behavior change.  I don't think people usually read all release notes for
all
updated facilities during automatic OS upgrades.  I went from 4.6.16 on
Slackware 14.2 to 4.18.9 on Slackware 15.0, so not very likely to read all the
release notes in between. 

Anyway, problem fixed and I would suggest that developers think twice about
altering default behavior for things are are signficant behavior changers.

--Mark