[Samba] Windows text file encoding vs Unix Samba server

[tlaronde at kergis.com]

On Thu, Feb 01, 2024 at 01:00:25PM +0000, Rowland Penny via samba wrote:
> On Thu, 1 Feb 2024 13:30:56 +0100
> Thierry LARONDE via samba <samba at lists.samba.org> wrote:
> 
> > Hello,
> > 
> > I have a NetBSD (currently kernel 9.2 without kernel ACL support)
> > server serving files via Samba to, mainly, a heterogeneous network of
> > MS Windows nodes with various versions, but the (new) problem I face
> > does not depend on the MS version or the cifs protocol version.
> > 
> > It used to work with Samba 3.6.* but it doesn't with 4.18.9 (the Samba
> > version installed).
> > 
> > Even when the Windows' user has full control other a (Unix) file, in
> > some cases: apparently always text or considered as text files, some
> > programs can't modify the file that the user totally controls and we
> > have to save under another pathname, before removing the old file and
> > putting the new version in its stead.
> > 
> > I thought, at the beginning, that there had something to do with the
> > names of temporary files (unable to create the temporary or to rename
> > the temporary). But there is no problem with the temporary names (they
> > are created).
> > 
> > There is no problem when a program handles a binary file (the program
> > can modify the file).
> > 
> > So I begin to suspect that this has something to do with localisation:
> > that the Unix file is declared, by default, to have a certain encoding
> > for a certain lang or that, in fact, nothing is declared related to
> > encoding or lang, so that the Windows client considers it can not deal
> > with a text file whose lang and encoding is unknown or for a
> > combination it does not support.
> > 
> > Is there something l10n/i18n related indeed in the CIFS protocol?
> > 
> > TIA for any tip or any link to documentation that may shed some light
> > on the subject!
> 
> I don't think you have given us enough information here to even guess
> at an answer.
> 
> What Windows versions are you using ?
>From Windows 7 (Pro) to Windows 11 (Pro). But same problem on every
Windows client

> How are you running Samba ?
with winbindd(8), nmbd(8) and smbd(8)

> Is there an AD domain involved ?
No.

> What 'program' or 'programs' are involved ?
Notepad; LibreOffice (when creating an xlsx or exporting to pdf);
sam (pdf 2 pdf converter).

> Could it be a 'locking' problem ?

The problem is that there is a problem, but that I'm trying to
identify what is wrong. So may be locking, but how can I know?

What is strange, is that the very same user can create a file; can
delete a file; but can't modify a file if it is not a binary file.

> What is in your smb.conf ?

Here it is (some network or user values edited):

---8<---
# Version 4.18.9
#
#======================= Global Settings =====================================
[global]
workgroup = AGROUP
server string = Samba %v (%h)
server role = standalone
security = user

idmap config * : backend = autorid
idmap config * : range = 100000-299999
passdb backend = smbpasswd

hosts allow = 192.168.xxx.0/24 127.

local master = no
domain master = no
preferred master = no

min protocol = core
max protocol = SMB3
client min protocol = core
client max protocol = SMB3
ntlm auth = true
hide dot files = No
acl group control = no

# Does it make any difference? The current kernel has no ACL support
# while the filesystem can have---but not mounted with support.
#
acl map full control = yes

blocking locks = no

log level = 2

#============================ Share Definitions ==============================
[shared]
comment = This Unix dir is shared with Windows clients
path = /some/dir
writable = yes
printable = no
valid users = one_user
write list = one_user
force group = users
vfs objects = acl_xattr
inherit owner = yes
inherit permissions = yes
--->8---

> There have been a lot of changes since 3.6.x

No doubt about that! ;-)
-- 
        Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C