Critical Regression: smbfs 7.0 introduces a crtitical bug regarding symlinks

App & System Services Core OS
mfh OP
Created
Replies 1
Boosts 4
Views 199
Participants 2

Apple feedback FB25355124

The SMB client no longer accepts reads to symlinks that are an absolute path to a network volume or a symlink that contains a (..) in the relative path.

Reproduction steps on an SMB mount with this file structure:

  • dir
    • a.txt

  1. Run this command from inside of "dir":

    ln -s my-link ../dir/a.txt

  2. Attempt to read that symlink:

    cat ./my-link

    Which results in this error:
    cat: link: Invalid argument

    which is translating to an EINVAL getting returned from the SMB client.

  3. Same behavior was observed when making a symlink with an absolute path:

    ln -s my-link /Volumes/Example/dir/a.txt

The server is responding successfully to the IOCTL command but the client is still rejecting the request with that error.

This behavior was not observed in macOS 26.6.2 (smbfs 6.0.1) as well as previous versions of macOS.

Replies  1
Boosts 4
Views  199
Participants  2
SNDWD OP

I can confirm the same issue on macOS 27.2 and macOS 27.3 Beta 1.

In my case, the SMB server is running TrueNAS CORE 13, and the affected files are Minshall+French (XSym) symbolic links.

I was able to reproduce the issue consistently:

  • Relative symlinks without .. work correctly.
  • Relative symlinks containing .. are incorrectly interpreted as regular 1067-byte files.
  • Long relative target paths without .. work correctly.
  • The same symlinks work correctly on macOS 14.8.8 when accessing the identical SMB share.

Disabling SMB metadata caching (nomdatacache), switching to SMB 2.1, and disabling SMB streams did not resolve the issue.

This regression is affecting production workflows involving linked media files.

I have also submitted a separate bug report: FB25362340.