(SMB from Mac Ventura) can not correct title case folder name unless it's different

[John45622]

Hi,

an odd one for mac users. So I have an SMB share (TN 23.10.2) mounted on Ventura 13.6.5 and all is good. Maybe some one can try and reproduce?

1) create a new folder using command-shift-N on the mac
2) Name the folder "TEST" all capitals and hit enter.
3) Now rename the folder to "test" all lower case and hit enter.
with my server the name changes to "test" for about one second and while I'm looking at the screen the name flips back to "TEST" all capitals.
Same happens when I just change one of the letters to lower case.
The only way I found to change the case it to first name the folder something different and then back to "test" and only then it will stick.

so

change name to "TESTx" hit enter works. then changing it to "test" also works. But renaming a folder by just changing the case of a letter does not work.
Is this an expected behaviour? I never noticed it before and it happens on all the SMB shares I have. (all setup as case insensitive)

I have permissions on this volume and all is working great otherwise.

Thanks!

 

[Samuel Tai]

Remember, SMB came from the Windows world, where things are case-insensitive, as the underlying FAT and NTFS file systems are also case-insensitive. I would say this is more or less expected behavior.

 

[John45622]

OK, but I am able to create a folders named "Test" or "TesT" or "TeSt" no problem and I have millions of folders and files on he server that are not all caps or all lower case, i just can't change the cases without changing the name as well. Really odd. I think I did not get this when the server was still running Core but I'm not 100% sure. I can also rename them to random jibberish in random cases like "kjahwdKJDHJBNDdjn" but i can not change any of those characters to upper or lower case in place. There's no error or anything given. The name changes and then changes back after a second while I'm watching.

If there's any mac user reading here who can try and reproduce at least I would now if this is something specific to my setup. That would be great.

 

[nabsltd]

On pure Windows, you see similar behavior until you force a re-read of the directory.

Try and monitor from another process and see if your issue is similar (i.e., just display). So, change the name using the Mac, but go to the console of the TrueNAS box and "ls" the directory to see if the name really changed.

 

[John45622]

I've come to the conclusion that this is normal. Even on the LucidLink service (which I assume is also some unix based service) that I use re-naming a name just by changing the upper/lower case leads to an instant error message "file already exists".

 

[anodos]

I've come to the conclusion that this is normal. Even on the LucidLink service (which I assume is also some unix based service) that I use re-naming a name just by changing the upper/lower case leads to an instant error message "file already exists".

It depends on underlying userspace tool behavior for case-insensitive filesystems. Many tools will first stat(2) the new name to check whether it exists, then perform the rename, but since filesystem is case-insensitive it literally confuses itself.

 

[anodos]

Code:

smb: \> ls
  .                                   D        0  Wed Mar 27 07:18:14 2024
  ..                                  D        0  Wed Mar 27 07:18:14 2024
  .DS_Store                          AH     6148  Tue Jan 16 10:03:12 2024
  truenas-samba_4.19.3+ix-1_amd64.deb      A 14189732  Thu Mar  7 13:56:21 2024
  During.svg                          A      579  Thu Mar  7 13:52:01 2024
  TrueNAS-SCALE-23.10.0.iso           A 33554432  Thu Mar  7 13:56:00 2024
  SERVER2022_DC_47347289-C91C-4675-90E3-D86048EED8C8.avhdx      A 25764560896  Mon Sep 11 11:02:52 2023
  truenas-samba-dbgsym_4.19.3+ix-1_amd64.deb      A  8388608  Thu Feb 22 03:59:19 2024
  TrueNAS-SCALE-24.04-MASTER-20230731-132134.iso      A 1576003584  Sun Aug  6 05:50:54 2023
  TrueNAS-SCALE-23.10.2-MASTER-20240130-051542.iso      A 1585502208  Thu Mar  7 14:01:18 2024
  TrueNAS-SCALE-24.04-BETA.1.iso      A 1607686144  Wed Mar 20 08:12:46 2024

                1879668992 blocks of size 1024. 1861448704 blocks available
smb: \> rename During.svg during.svg
smb: \> ls
  .                                   D        0  Wed Mar 27 07:18:45 2024
  ..                                  D        0  Wed Mar 27 07:18:45 2024
  .DS_Store                          AH     6148  Tue Jan 16 10:03:12 2024
  truenas-samba_4.19.3+ix-1_amd64.deb      A 14189732  Thu Mar  7 13:56:21 2024
  during.svg                          A      579  Thu Mar  7 13:52:01 2024
  TrueNAS-SCALE-23.10.0.iso           A 33554432  Thu Mar  7 13:56:00 2024
  SERVER2022_DC_47347289-C91C-4675-90E3-D86048EED8C8.avhdx      A 25764560896  Mon Sep 11 11:02:52 2023
  truenas-samba-dbgsym_4.19.3+ix-1_amd64.deb      A  8388608  Thu Feb 22 03:59:19 2024
  TrueNAS-SCALE-24.04-MASTER-20230731-132134.iso      A 1576003584  Sun Aug  6 05:50:54 2023
  TrueNAS-SCALE-23.10.2-MASTER-20240130-051542.iso      A 1585502208  Thu Mar  7 14:01:18 2024
  TrueNAS-SCALE-24.04-BETA.1.iso      A 1607686144  Wed Mar 20 08:12:46 2024

So this is a MacOS rename bug.

 

[dak180]

When I have seen this before it was as a result of the dataset being case sensitive but smb not having the metadata set to declare this; macOS then assumes that it is working with a case aware (meaning insensitive) file system (the default for the os) and all sorts of oddness ensues. Try adding case sensitive = true to the smb share aux parameters and restart smb. This is what I had to do on core to make things work properly.