SOLVED: Bug in Electric Eel RC1 SMB Service with MacOS 15.0?

Right, so what I am trying to say if maybe the CURRENT code is what they looked at that that code had no issues. But maybe the code when you migrated did have issues. Just a thought.

My shares no default share parms. What is ACC? I’m looking at my SMB parms and I don’t see anything like ACC. Really, mine are all default settings just not sure what you turned on for ACC. Well, you apparently said it earlier, Apple Characterset Compatability. I don’t see that box. You mean Apple Style Character Encoding maybe? Mine is turned off. I guess I do not use any non standard characters. Is there a danger?

In my case:

  • There was no migration/transition from Core. Rather a brand new ElectricEel-24.10.2 installation. (I’ve never used Core.)
  • No MacOS. Rather an Ubuntu 24.04 client mounting multiple Truenas smb shares. (Though I do have some MacOS clients to hook up in the future.)

I first witnessed this filename mangling issue with:

The filename on disk is the original ‘filename_ending_in_period.’ from the perspective of the Truenas shell.

So the culprit must be filename handling in the smb protocol between client and server. I believe the smb protocol performs filename mangling on purpose, in deference to Windows.

All I know is I want filenames that are legal at the client (linux), and legal at the server (linux), to show up unmangled in an smb share mounted by the client (linux).

Another smb share experiment:

  • Purpose: Multi-protocol (NFSv4/SMB) shares. Mangled.
  • Add ‘Use Apple-style Character Encoding’. No mangling.

Another experiment: I asked a friend with Synology NAS and Ubuntu client to try my “filename ending in period viewed from mounted smb share” experiment. Long story short the filename was mangled (in his case mangled merely by removing the offending period at the end of the filename rather than a complete renaming as in my case). Don’t know how his synology server is configured or what the filename on disk ended up looking like from his server’s perspective.

Just reporting some experiments and observations. Happy that I found this setting. Wish it wasn’t so obscure. Seems like this setting is not specific to Apple clients, but to linux clients as well.

1 Like

I see, yes, a filename ending in a period is mangled on Latest MacOS. I don’t have any of those (or any other special characters), so, probably won’t bother with the option. Those are the “fruit” settings in Samba.

Thanks for the observations.

1 Like

Per guidance above, ACC should not be turned on / off vicariously.

Likely, it’s safest to enable at dataset / share inception, not later. IIRC, I had to do it with existing shares when I transitioned the NAS from using AFP to SMB on CORE several years ago. AFP was compatible with Apple file names / characters, SMB needed ACC to be turned on.

That “mid-life transition” for the affected shares was not a problem for switching a dataset share from AFP to SMB - as long as ACC was turned on.

I’ll wager a ham sandwich that turning off ACC after having had it on for a while would become the pinch point once users have had the opportunity to populate the dataset with file names that are not compatible with core NFTS allowable file system characters or whatever.

This is why I needed to reenable ACC for SMB on my NAS after ACC mysteriously turned off for all non-Time Machine shares. Once ACC was back on, all SMB shares returned to just work as expected.

1 Like