Package: samba
Version: 4.22.0
Hi,
I am testing Debian Trixie, and I believe I have identified a regression
in the Samba server package.
Description
-----------
The issue has to do with the listing of shares containing files or
directories with names including special characters such as double quote
(") or backslash (\).
When such a character is present in any of the files or directories
within a shared folder, then the content of that folder will not be
listed at all on a Windows client (tested with a fully up to date
Windows 11 24H2 client) or may even produce a "not accessible" error.
This is a regression from 4.17.12 (tested on Debian Bookworm) where the
content will be listed (albeit with the files containing special
characters potentially appearing using their DOS names, such as
'T3VHSW~N' rather than their actual name).
Steps to replicate
------------------
Create a samba share and mount it under a Windows client.
Then, on the Linux server, issue the following commands to create files
containing Windows "special" characters in the shared directory:
touch test\ with\*
touch test\ with\:
touch test\ with\<
touch test\ with\>
touch test\ with\?
touch test\ with\|
You will see that, despite using "special" Windows characters, these 6
files appear in the share (NB: This may vary depending on the file
explorer being used. I have mostly been testing using Directory Opus as
a file explorer client, as it does a better job than the default Windows
file explorer) and can be listed from the Windows client (thus
undermining the possibility that the issue is a blanket one with using
special 'disallowed' characters) and, when listed by the explorer, they
are using the (unmangled) names they have been declared with.
Then create another file, containing a double quote:
touch test\ with\"
From the Windows client, you will see that this file does not appear.
Furthermore, if you restart the Samba server (service smbd restart) you
may may get a "not accessible" from Windows File Explorer when trying to
access the share, or, when using a different explorer application, see
that the whole content from the folder disappears.
Running the same test on Debian Bullseye with Samba 4.17 shows very
different results, where, even if you restart the smbd service, the
content of that directory does remain accessible, albeit with files
containing special Windows characters using mangled DOS names.
So, while there does appear to have been improvement when it comes to
listing of files and directories containing Windows special characters
between 4.17 and 4.22, since (depending of the file explorer) they may
now appear under their actual declared name, there also seems to be
regression when there happens to exist a file or folder containing
double quotes.
Note that the same issue also manifests with files containing
backslashes, though of course, is is slightly less problematic than the
one with double quotes, as native Linux files containing backslashes are
expected to be very rare, whereas native Linux files containing double
quotes are relatively common.
Additional comments
-------------------
Testing with smbclient shows that smbclient is able to properly list the
content, so part of this issue seems to be with how the Windows 11 24H2
SMB client behaves when it encounters file names with special characters:
---------------------------------------------------------------------
pete@nas:/mnt/ssd/g# smbclient //nas/share -c 'cd test;ls;' -U pete
Password for [WORKGROUP\pete]:
. D 0 Fri Mar 28 11:22:35 2025
.. D 0 Fri Mar 28 10:31:34 2025
test with? N 0 Fri Mar 28 10:50:04 2025
test with< N 0 Fri Mar 28 10:50:10 2025
test with> N 0 Fri Mar 28 10:50:26 2025
test with| N 0 Fri Mar 28 10:50:40 2025
test with: N 0 Fri Mar 28 10:53:05 2025
test with* N 0 Fri Mar 28 10:53:32 2025
test with" N 0 Fri Mar 28 11:22:35 2025
---------------------------------------------------------------------
Therefore, if the issue is that Windows can handle content with ? < > |
: *, but not " \, I would suggest that samba reverts to the old
behaviour of listing the latter using the mangled dosname, so that
people upgrading to Trixie aren't going to be left wondering why a
shared folder, that happens to contain a file with a double quote, and
that was listing content in Bullseye, is now no longer accessible.
Regards,
/Pete
