Directory case sensitivity issue with macOS client

[Mark Levitt]

Hi,

I'm trying to figure out a strange issue where I have two directory names that differ only by case. Specifically, I have one directory named "Lady Gaga" alongside a second directory named "Lady GaGa" (notice the difference case of the second 'G'). I'm sharing the dataset via SMB and connecting to it with a macOS Mojave (10.14.6) client.

From the Finder, it sometimes shows both directories with their different case names. However, whichever one I open, it only shows the contents of the one with the uppercase G. Then, if I go back to the parent directory, it shows two directories with the same identical name and case for a split second. Then it changes one of them back to a lowercase g.

The contents of the two directories are different (the one with the lowercase g has an extra sub directory). However, from the Mac, I can only access the one with the uppercase G.

Accessing the Freenas share via SSH, I can see and access both directories:

Code:

freenas% cd Lady\ Gaga
freenas% ls -l
total 113
drwxr-sr-x  2 mlevitt  family   4 Jun 30  2014 Marry the Night - Single
drwxr-sr-x  2 mlevitt  family  27 Aug 14  2013 The Fame Monster
freenas% cd ..
freenas% cd Lady\ GaGa
freenas% ls -l
total 49
drwxr-xr-x  2 mlevitt  family  4 Jun 21  2017 Marry the Night - Single

From the mac terminal, it sees both cases, but no matter witch one I CD into, I always get the contents of the directory with the uppercase G, like in the Finder.

Code:

➜  Music cd Lady\ Gaga
➜  Lady Gaga ls -l
total 32
drwx------@ 1 mlevitt  staff  16384 21 Jun  2017 Marry the Night - Single
➜  Lady Gaga cd ..
➜  Music cd Lady\ GaGa
➜  Lady GaGa ls -l
total 32
drwx------@ 1 mlevitt  staff  16384 21 Jun  2017 Marry the Night - Single
➜  Lady GaGa

This is the SMB share configuration:

Code:

[iTunes]
    aio write size = 0
    ea support = No
    level2 oplocks = No
    mangled names = illegal
    oplocks = No
    path = /mnt/tank/iTunes
    read only = No
    strict locking = Yes
    vfs objects = fruit streams_xattr zfs_space zfsacl
    nfs4:acedup = merge
    nfs4:chown = true
    fruit:resource = stream
    fruit:metadata = stream
    streams_xattr:store_stream_type = no
    streams_xattr:prefix = user.
    fruit:locking = netatalk
    

The dataset was created using the default "sensitive" case sensitivity. Could that be the problem?

FreeNAS is at version 11.3-U4.1.

Any idea?

 

[anodos]

What is output of "zfs get casesensitivity tank/iTunes"?

 

[Mark Levitt]

Code:

freenas% zfs get casesensitivity tank/iTunes
NAME         PROPERTY         VALUE        SOURCE
tank/iTunes  casesensitivity  sensitive    -

 

[anodos]

Can you please PM me a debug?

 

[Mark Levitt]

Sure thing. Sent.

Thanks!

 

[seanm]

Mark, with macOS Disk Utility.app, could you try creating a disk image using case-sensitive HFS or APFS and see if you reproduce the same issues? If so, then it's a macOS bug.

 

[Mark Levitt]

Hi,

Sure. Works exactly as expected. I created a case-sensitive APFS volume, mounted it, and created two identical directories with different cases. I was able to enter and create files and view them with Finder and from the terminal.

Code:

  TestDiskImage ls -lR
total 0
drwxr-xr-x  3 mlevitt  staff  96 18 Aug 16:06 Lady GaGa
drwxr-xr-x  3 mlevitt  staff  96 18 Aug 16:06 Lady Gaga

./Lady GaGa:
total 0
-rw-r--r--  1 mlevitt  staff  0 18 Aug 16:06 uppercase_G

./Lady Gaga:
total 0
-rw-r--r--  1 mlevitt  staff  0 18 Aug 16:06 lowercase_g

 

[Mark Levitt]

I've noticed the same behaviour on my Freenas home directory via SMB, so it's not just that share.

 

[anodos]

If you _only_ have MacOS SMB clients, then you can set case sensitive = true as an auxiliary parameter.

 

[Mark Levitt]

Hi,

I'll give it a try, but do you mean if I only have MacOS clients vs non MacOS or do you mean SMB vs AFP?

 

[anodos]

Hi,

I'll give it a try, but do you mean if I only have MacOS clients vs non MacOS or do you mean SMB vs AFP?

SMB. SMB2 is _always_ case insensitive unless this parameter is set to non-default value.

 

[Mark Levitt]

OK, setting case sensitive = true seems to have fixed the problem. Should this be the default for any installation using only SMB, rather than AFP?

 

[anodos]

OK, setting case sensitive = true seems to have fixed the problem. Should this be the default for any installation using only SMB, rather than AFP?

No. The current default is correct.

 

[Mark Levitt]

OK, but I'm confused about why the default doesn't work properly, then. Is there something non-standard about how I've configured the server or clients? I don't think I've done anything to change the out of the box behaviour of SMB on the mac and the freenas shares are using the defaults.

 

[anodos]

OK, but I'm confused about why the default doesn't work properly, then. Is there something non-standard about how I've configured the server or clients? I don't think I've done anything to change the out of the box behaviour of SMB on the mac and the freenas shares are using the defaults.

Windows is case-sensitive but case preserving.

 

[Mark Levitt]

So out of the box, it doesn't work properly for Mac clients unless you add that flag? Perhaps that should be documented?

 

[anodos]

So out of the box, it doesn't work properly for Mac clients unless you add that flag? Perhaps that should be documented?

No. It works correctly. Behavior is identical to a Windows server.

 

[seanm]

Windows is case-sensitive but case preserving.

Typo? Don't you mean case-insensitive but case-preserving?

 

[anodos]

Typo? Don't you mean case-insensitive but case-preserving?

Yes. Typo.