A Windows 10 ESU client has copied a folder tree containing folders with trailing spaces to a SMB share hosted on SCALE 25.10.4. This is not normally possible on Windows because it will drop any trailing spaces, instead these folders with trailing spaces were created programmatically using the application Syncovery (trailing spaces are allowed on Google Drive, which was the folder tree source). I walked through the issue with the Syncovery developer and he assured me that the issue is with TrueNAS SCALE.
The issue is that any folders created that have trailing spaces revert to the legacy 8.3 naming scheme. When I try to rename the 8.3 formatted folder in File Explorer I get an error “Item Not Found”.
When I try to enter into that 8.3 formatted folder’s structure I get an error “Location is not available“.
Trying Syncovery to copy the folder with the trailing space to a Win 10 local storage (leaving the trailing space intact) and then using File Explorer to copy the folder with the trailing space to the SMB share causes an error “1 Interrupted Action“.
Logging into TrueNAS command line, the folders with the trailing space all appeared normal and were navigable. Using the TrueNAS command line to rename the folders with the trailing space as the same name minus the space completely resolved the issue. I am able to use Syncovery to repeatably recreate this issue with 100% reproducibility, and then resolve it in the TrueNAS command line with 100% reproducibility.
Please let me know what sort of information you need in order to investigate this issue and I’ll see what I can provide.
EDIT: Note that using Syncovery to copy the same dataset to a NTFS formatted storage local to the Windows 10 client has no issue - Windows just ignores the trailing space it seems. But then using Syncovery again (File Explorer will refuse to do it, see above error) to copy that same dataset from the Win 10 client local storage to TrueNAS SCALE results in the same problem, so this does not appear to be a Windows issue.
trailing spaces are invalid in win32api IIRC.
I’ll restate the issue more strongly now that I know more about it: TrueNAS SCALE middleware is broken in the way that it handles files/folders with trailing spaces for Windows SMB clients. Below I discuss what to do about it.
Whitespace characters in file and folder names - Windows Client | Microsoft Learn
Thanks for this resource. I have since discovered that it would seem that any program that doesn’t use the win32api create/copy/move function seems to be able to create this problem. So far that includes Syncovery and Teracopy. For Teracopy, you can use it to copy/move any source file/folder containing a trailing space and it will copy/move and the destination file/folder will revert to the 8.3 naming schema, which upon TrueNAS CLI inspection does have a trailing space, as described in my original post.
So the question is what should TrueNAS SCALE do for these types of files/folders for Windows Clients using SMB shares? Clearly what it’s doing now is broken because it is resulting in files/folders that cannot be read by a Windows client. The way SCALE handles it now, because Windows handles folder/file names with trailing spaces differently than Linux, there will inherently be a discrepancy between saving a folder/file with a trailing space to the SMB share using the Windows client vs with the Linux client. Because Windows won’t allow you to create/copy/move a file/folder with a trailing space (win32api intervenes to remove the space) the scope of the question just covers the edge case for files/folders created/copied/moved without using the win32api create/copy/move function. Fortunately I think I have a solution that works for all client types.
The solution is as follows:
Conform to the above hyperlinked policy. It states:
“If a file is saved as 'Foo.txt ', where the trailing character(s) is an ASCII Space (0x20), it will be saved to the file system as ‘Foo.txt’.“
This would require, as far as I understand, the following changes in the middleware:
-
The middleware allows the creation/copy/move of files/folders with trailing spaces when a Windows client writes a file/folder to a SMB share. This will only happen when a file/folder is created/copied/moved programmatically in a way that doesn’t use the win32api (which is the only way to create a file/folder with a trailing space in Windows). Doing this would be different from the win32api behavior which removes trailing spaces from files/folders upon creation/copying/moving. This is not technically a change, clearly the middleware already allows it (hence my issue), but it is important to mention that it should be allowed. I think it should be allowed so that files/folders with trailing spaces can be created/copied/moved programmatically without win32api as the user/developer desires. Keeping the trailing space intact will ensure a 1:1 match between the source and destination datasets when programmatically creating/copying/moving files without win32api.
Alternatively the middleware could be changed to drop trailing space, which is what the win32api does. Doing this will break the 1:1 file/folder match between the source and destination datasets which I think should be avoided.
-
The middleware presents files/folders with a trailing space as files/folders without a trailing space (just as the win32api does) to Windows SMB clients. In this case a Windows client is free to do its business with these files/folders as if the trailing space doesn’t exist (as win32api intends) and then when a Linux client accesses the files/folders it sees the trailing space as expected.
The middleware should not intervene when a Linux client is writing a file/folder to a SMB share because a trailing space is allowed in Linux.
Overall, the solution allows Windows clients to programmatically create/copy/move files/folders with a trailing space without win32api leaving the trailing spaces intact, while also allowing the client to work with the dataset on the SMB share despite having trailing spaces. The solution works for environments with a mix of Linux and Windows clients accessing the same SMB share too.
AFAIK, the TrueNAS Middleware isn’t doing anything with the files.
Samba is. Samba is an open source implementation of Microsoft’s SMB protocols that TrueNAS uses.
So to reiterate, changing how spaces are handled in file names shared over SMB would require a change in Samba, not the TrueNAS middleware.
Having to make arguments to the Samba developers was not the outcome I was hoping for 
But I will try with them. It does make sense for this to be a Samba issue. If someone else could please confirm before I go down the rabbit hole on Samba that would be appreciated.
It’s most likely due to Samba, but you might want to spelunk through the middleware itself in /usr/lib/python3/dist-packages/middlewared to double-check. Specifically, the SMB pieces are in smb.py and the smb_ directory. From my quick perusal, these portions of the middleware just dynamically modify the Samba smb.conf file or run-time temp files in /var/run/samba*.
It would also require changing behavior of Windows clients in general because the trailing space is invalid in win32. So you might also have to complain to microsoft.
Windows can deal with spaces anywhere in a filename (use quotes).
SMB cannot deal specifically with trailing spaces, but you can make it work:
Enclose the path in quotes and use the \\?\UNC\ prefix.
The developer of Syncovery had the following to say, he thinks that we are all mistaken (certainly a possibility) on some things:
”Windows will NOT generally drop trailing spaces. It can handle them just fine.
Only Windows “File Explorer” does not like them when you create a new folder yourself. But it will handle folders with trailing spaces without issues.
There are zero problems when using Windows servers as SMB server instead of TrueNAS.
Even Linux or other NAS systems don’t have a problem.
Nonetheless, it can be reasonable to replace trailing spaces.
But note that this is ONLY needed for this unusual NAS and not for Windows in general, or for other NAS brands. I think they still have some SMB settings that were intended for Windows versions of the last century. Not today’s.”
So he is claiming:
- win32api handles trailing spaces just fine, instead it is File Explorer that tries to drop the trailing space. I have confirmed this by using Syncovery to copy the dataset to local storage on the Windows client and indeed the trailing spaces are left intact which is made clear when I try to rename the files/folders in File Explorer which then makes the trailing space visible.
- Other NAS products that use Samba (“Even Linux or other NAS systems“) don’t have the problem that we are seeing here. Well this is false since SCALE is Linux. But if what he is claiming is that SCALE does something different that makes this issue happen, then that can be tested for. Give me some time and I’ll test this with another Linux host that uses Samba.
Ok I’ve just confirmed that this is a TrueNAS SCALE 25.10.4 issue. I used Syncovery to copy the dataset over to another Linux Samba SMB host (UnRAID 7.3.2) in the same exact way that I did in the descriptions above and the files/folders with trailing spaces do NOT revert to the legacy 8.3 naming schema on the UnRAID host. Instead I can enter into that folder tree and use it as normal.
So…. What do I do next? I don’t have the rights to create a Jira ticket on Ixsystem’s issue tracking platform. Or at least there’s no Create Issue/Ticket button anywhere I can find.
Use Report a Bug in the TrueNAS GUI. Looks like a smile on the upper right for Feedback / Report a Bug. Make sure to attach a Debug Dump along with all info you tested. There is also Report a Bug link on top, upper right of the forum.
Be as detailed as possible as they might attempt to reproduce.
This is upstream samba mangled names behavior and it has to cover the gamut of existing SMB clients to not break compatibility with them. We’re not going to change defaults here because it would also allow other illegal characters that can break clients (mangled names =no). The correct avenue if you strongly believe it’s improperly included in the schema that needs to be mangled is to report issue to upstream samba project. Once again, this is not a TrueNAS bug.
