Name Mangling problems with Mac OS Client

TrueNAS General
,
1

Hi

Apologies in advance for the long-winded nature of the post…

I’m new to TrueNAS Scale, and I’m migrating my data from Synology to TrueNAS. I’m using TrueNAS Scale 25.10.1, with a Mac OS client running Mac OS 15.7.2

The Problem

In a test migration of my data I found that a small number of files failed when using rsync to copy the files across. The affected files had characters such as “?” or “/” in their filenames.

Investigation…

This prompted me setting up shares with each of the presets, with and without apple encoding enabled as I wanted to properly understand the behaviour. Thus I created test shares with the following purposes:

“Default”, “Time Machine”, “Multi-protocol”, “Private Share”, “Final Cut”, “Time Locked"

I also created a test share with “apple encoding” enabled where that option existed - that is for the following purposes:

“Default”, “Multiprotocol”, “Private”, “Time Locked”

I then created two test files on my Mac OS client: “This is is a test?” and “This is a test 2/2" (i.e. the files have an illegal NFTS char in the filename)

I found that attempting to copy either of the two files to any share with apple encoding enabled would result in the following error:

The operation can’t be completed because one or more required items can’t be found.
(Error code -43)

This seemed odd as I was expecting any file with a valid MacOS filename to be successfully copied to a share with apple encoding enabled - so clearly a gap in my understanding here.

Taking a look at the smb4.conf file , it seems that enabling apple encoding makes the following changes to the config file in all cases:

  • fruit:encoding = native
  • mangled names = false
  • vfs objects = + catia

I didn’t spot any other changes.

Now, I’m not completely clear what the intended effect of turning on “apple encoding” is, and I’m not sufficiently familiar with samba configuration to infer the intended operation from the 3 lines of config above.

However, it does seem strange that copying a file with a valid MacOS filename from a MacOS client to a share will reliably fail in apple encoding is enabled.

Can anyone shed any light on this?

Many thanks

Pete

2

AFAIK all of these are forbidden in file names when using SMB, some are forbidden by MacOS itself:
? * / \ : | " < >

If such a file is handled by SMB in some way the name will be mangled to keep the file accessible. At least if SMB is set up properly.

There may be more. //Edit The full list is available on github and you can use something like this conversion table if you don’t read hex.

3

Hi

Thanks for that.

As far as I know, the only strictly forbidden character in filenames on MacOS is ’:’ . Some are obviously very unwise ( such as ‘<‘, ‘>’) - nevertheless you can use them if you so wish. Personally, I’ve never had a problem with ‘/’ or ‘?’ on MacOS - at least since Snow Leopard (~2009).

I’ve not had an issue with files with ‘/” or ‘?’ in the filename on my Synology.

From a TrueNAS Scale SMB perspective,

  • TrueNAS transparently handle files with filenames that include ‘/’, ‘?’ where Apple Style Character Encoding is NOT enabled, with no problems - so that’s OK.

BUT

  • filenames that include ‘/’, ‘?’ generate an error when copying to a share that has Apple Style Character Encoding is enabled

So there are clearly SMB configs that mangles the names appropriately.

The real question here is:

Why don’t the standard share purposes handle mangling of valid Mac OS filenames when Apple-style Character Encoding is enabled? Especially as modifying the smb config (other that via the UI) is discouraged.

I don’t know whether :

  • the current behaviour of Apple Style … is as intended
  • or, there is some other configuration setting that I need to make (I can’t see it!)
  • or, I’m completely misunderstanding how Apple Style … should be used.
  • or, there is a bug or some other sw issue (probably unlikely)

[You could of course argue that using the above chars was unwise - but that is a separate issue - we are where we are as they say.]

Thanks

4

Hi,

welcome to the party ;(

ref01.

ref02.

5

Thanks - useful background.

I’ve not had any problems previously - possibly because there hasn’t been a Windows machine in the household for close to 20 years (other than in the odd VM to do something that simply can’t be done on Mac OS / linux).

I guess the simple answer is not to use apple encoding at least for now. That is a bit uncomfortable as I really don’t want to migrate close to 20TB without fully understanding this. Not my way.

One of the references you kindly provided was a somewhat inconclusive. Some people have had success by using datasets with some specific settings. I’m not inclined to take that approach without further investigation, and I can at least create a SMB configuration (without Apple encoding that works).

I could use something like convmv - but its complicated by the impact on related linked metadata

The documentation on this topic is somewhat limited unfortunately.

Cheers