1

Sometimes in Finder on Mac OSX users cannot see some files.

Which files are not visible seems random.

It doesn't depend on the version of Mac OSX, and doesn't depend on the version of SMB. I have Samba 4.17.12 server which is part of Debian 12. The same problem occurs with Debian 11, or with different versions of Samba.

It has been occurring about five years.

It is not caused by permissions. Files in folder can have exactly same permissions, sometimes almost same names (differs only in one ASCII character for example), but in Finder users can see only some of them.

Users reported - these invisible files are sometimes visible in Finder for very short time, less than one second, then the files disappear.

Is it a bug in Finder?

Sometimes helped remove all characters with diacritics from filenames and leave only basic ASCII.

Sometimes helped do some minor change in file (for example add empty line in word document) and it magically appeared in Finder again.

Never helped move invisible file in other folder, it always stayed invisible.

I tried many changes in smb.conf without success. It always works with Windows 7, 8, 10, 11 or with smbclients on Linux.

I tried removing .DS_Store and other ._ metadata from Mac, never helped.

I tried reloading Finder on Mac OSX, reboot Mac... never helped

In logfile I can see Mac is accessing all files, even files invisible in Finder. I didn't find any relevant message in log file.

Macs and Windows are using both protocol SMB 3.11 and encryption AES-128-GCM, there is no difference.

# SIMPLIFIED CONFIG [global] netbios name = xxxx netbios aliases = xxxx.localnet server string = xxxx os level = 99 time server = yes server signing = mandatory smb encrypt = mandatory dos charset = CP852 unix charset = UTF-8 security = user local master = yes preferred master = yes wins support = yes admin users = administrator domain master = yes min protocol = SMB2 idmap config * : backend = tdb idmap config * : range = 3000-7999 vfs object = recycle dns proxy = no mangled names = no access based share enum = true [sharename] comment = share comment path = /home/someshare browseable = yes create mask = 0660 directory mask = 0770 force create mode = 0660 force directory mode = 0770 force group = users read only = yes valid users = username1 write list = username1

Do you have an idea what to check?

I don't know if it is bug on Mac or Samba. I suspect it is Mac problem, but I have no idea how to confirm.

Improve this question

4 Answers 4

Reset to default
1

I have had the same problem but with folders, and I noticed that folders with names less than 7 characters cannot be seen. I do not know how to solve it because it is a problem in macOS. However, I have been able to see the same folders in Windows and Linux. I checked this by changing the names directly on the server. I gave them longer names, and immediately they synchronized, and I could see them in the Finder.

Improve this answer
1
  • Looks like Windows and Linux omit LFNs when they aren't really needed (where filenames are short), but macOS requires them all the time. Commented Jun 25, 2024 at 6:49
1

We have been experiencing a similar issue. In our case, the invisible files have one thing in common, they all contain combining diacritic Unicode characters (U+0301, U+030A, U+030C).

Unicode has two ways to represent for example an acutely accented A.

  1. A single precomposed character: U+00C1 Latin Capital letter A with acute, UTF-8: 110 000 11 10 00 0001
  2. A combining character combined with a regular ASCII A: U+0041 Latin Capital letter A U+0301 Combining Acute Accent, UTF-8: 0 100 0001 110 011 00 10 00 0001

Files that use only the precomposed variants are visible.

If your shell supports ANSI-C quoting (e.g. bash), you might be able to search for problematic files with find . -regex $'.*[\u300-\u36f].*'. Of course, the range can be adjusted to your needs. This one covers the whole Combining Diacritical Marks Unicode block.

Improve this answer
1
  • Thank you very much. I found exactly this week or two ago, but i am still not sure which option in smb.conf did help solve problem with UTF-8 encoding. It did try this unix charset = UTF-8 display charset = UTF-8 and fruit:encoding = private fruit:resource = file fruit:posix_rename = yes fruit:veto_appledouble = yes fruit:wipe_intentionally_left_blank_rfork = true veto files = /.AppleDouble/ Some of it did help, maybe combination of unix charset and fruit:encoding? Commented Oct 9, 2024 at 11:55
1

I was experiencing a very similar issue. I couldn't access Samba remote directories when using Finder on my Mac. Some “can not access… missing privilege” exception was showing up. No matter what I tried in the Samba configuration, with chmod or chown, I could still not access the files. In the terminal, they would be accessible. By coincidence, I noticed, that all directories were dated to 01.01.1970.

touch -t 0510240303.03 foo

set the timestamp on my foo-directory to something or something else than 01.01.1970. Suddenly the files were showing up even in Finder and my issue was solved. I hope this helps you as well.

Improve this answer
0

This problem might happen if some program running on Mac like Office or Adobe renames a file to be hidden and then renames again to non hidden. In Mac and Linux, renaming to a file name starting with . makes it hidden. Renaming again without a prefix of . makes it non-hidden.

But with Samba (since 4.9.0) the hidden attribute is written as well to disk as an extended attribute. And this attribute is not modified on rename. In other words - the hidden bit is then "stuck" to the file, no matter if it is renamed to be without the prefix ..

If only Mac users are accessing this share, you could solve this problem by adding to smb.conf the entry "hide dot files = no". The only cost of this is that Windows users will see the "dot files", the ones Mac users wanted to hide.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.