Need help understanding interaction bwteen Mac and SMB share on Truenas

I have a TRUENAS-MINI-3.0-X+ running TrueNAS-13.0-U6.1. I have a M1 Pro Macbook Pro running the latest 15.2. The NAS has an SMB share called Users. The Mac, I guess, at this point in time, supports only SMB and no longer supports AFP. I don’t know that to be true but that’s what I’ve been led to believe.

I mount Users on the Mac in the usual /Volumes. I mount it via the GUI in the Finder.

Yesterday I discovered that symblic links on the NAS completely disappear on the Mac’s view of the share. To rephrase, ls -l in a directory that is within the Users file system does not show any of the symbolic links. The Finder as well does not show any of the symbolic links.

Today, I discovered another oddity. A file named 2023-08-07T09:47:04Z.gpx on the NAS shows up as 2YJ9JZ~H.GPX on the Mac. It has the same contents. i.e. cmp returns 0. I copied the version on the NAS over to the Mac via rsync and then did the compare. The resulting name of the file from the rsync is the same as what is on the NAS.

The command mount | grep User on the Mac displays

//pedz@truenas._smb._tcp.local/Users on /Volumes/Users (smbfs, nodev, nosuid, mounted by pedz)

If it matters: the way I create what is on the NAS is via rsync. I create it originally on the Mac and then use a pretty normal rsync command to push it over to the NAS. e.g. rsync -av localpath truenas:remotepath Up until now, I thought mounting the share via SMB would give me exactly what was on the share but now, obviously, that isn’t true.

I have rebooted both the NAS and my laptop. Can anyone help me understand what is happening and if there are ways to remedy the situation. I’m not really hamped currently with either of these situations but it is really confusing to me. What other oddities will I encounter? I’ve ask this question on a Mac forum without reply. I thought I would try here.

Thank you for your help

MacOS has some strange behaviours:

Were the symlinks working previously or were they just being stored?

Can you test by creating a share with SMB directly… do you see similar issues?
If not, its liklely to be an rsync issue.

It’s the colons in the case of the gpx files.

On the NAS I do:

touch abc:def

From the command line on the Mac cd’ed into the SMB share at the same point I see:

# ls

APJCKU~G

I don’t do Windows… but I vaguely recall perhaps in the distant past, a colon was special in file names?

Likewise, on the NAS I do

ln -s /abc/def/ghi .

and nothing shows up on the SMB share. I probably should have done these simple experiments before posting my note. The symbolic links didn’t blow my mind since I guessed Windows doesn’t have symbolic links. But the weird gpx file names really confused me.

The filenames for the gpx files are for time stamps. I need to figure out a different character other than colon… or just not use the SMB share for these files.

Your reference helps also… Thank you

1 Like

Paths on HFS use colon to delinate folders (directories). So same prohibition as using slash within a Unix file name or backslash within a Windows file name.

Ah yea… thank you for reminding me.

I’ve exported the share from the NAS via NFS. I got it to mount via the command line but now I have user id mapping issues to figure out. I can’t get it to mount via the Finder’s command-K.

I believe that it does matter. Depending on what features of the file system you use in what you write to the TrueNAS file system via rsync, it might matter a great deal.

Remember that when your Mac writes files to the TrueNAS server via SMB, there is Samba software on the server which handles that request. It stores the files on the TrueNAS file system as a backing store. It may represent certain file names in a modified way on the backing store. It may modify how it represents file permissions, extended attributes, and symbolic links. Then when your Mac reads server files via SMB, the Samba software on the server reads the files from the backing store, undoes the modifications, and presents the files to the Mac in their original form.

When you deliver files to the TrueNAS file system via rsync, you are bypassing the Samba encodings or modifications to those files. You might put something into Samba’s backing store which it doesn’t expect. And in the case of filenames with colons, it looks like you did.

There are two ways to proceed. One is to deliver all files to the server via SMB, so that Samba software can write them to the TrueNAS file system in a way Samba expects. This may, however, run slowly. Another is to deliver via rsync, but be careful that your files use only filenames and features which are acceptable to Samba in their literal, unmodified form.

colon is a reserved character that’s used to separate stream names. See ADS test here: middleware/tests/api2/test_425_smb_protocol.py at b4875cc8a734542a95f82dd51a0e643e229f0a4a · truenas/middleware · GitHub

If you’re using SMB protocol you should try to avoid using reserved characters in file names. Generally the MacOS client is good about this. It will replace the : with something equivalent in unicode private range for the write. The place where people get into trouble is when they write data through a different protocol and then try to read it over SMB.

When you’re putting data onto a truenas (or really any) SMB share, it should go through the SMB protocol to ensure that the client writes things in the way it expects them to be.