Rowland Penny
2024-Feb-01 13:00 UTC
[Samba] Windows text file encoding vs Unix Samba server
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 ? How are you running Samba ? Is there an AD domain involved ? What 'program' or 'programs' are involved ? Could it be a 'locking' problem ? What is in your smb.conf ? There have been a lot of changes since 3.6.x Rowland
tlaronde at kergis.com
2024-Feb-01 13:40 UTC
[Samba] Windows text file encoding vs Unix Samba server
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 everyWindows 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.xNo 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