Samba not working on Sequoia

Hello, it seems that for whatever reason, the way of resolving the SMB hostnames has changed on Sequoia, at least on my computer.

I used to connect to a NAS at smb://MyCloud-UT6A4L.lan on Sonoma, now I need to connect to smb://MyCloud-UT6A4L._smb._tcp.local

Likewise, if I want to connect the computer to itself like you tried, and even if the sharing parameters point me to connect to smb://mbp-de-matthieu.lan, I actually need to connect to smb://Macbook Pro de Matthieu._smb._tcp.local (including whitespaces !)

I haven't found yet the syntax to connect through IP addresses.

Looking around the internet, it seems that this ._smb._tcp.local suffix has existed before Sequoia, so I assume it has been a valid syntax for some time, but that there is currently a bug with the "regular" (and more straightforward) SMB syntax.

I would not be messing around with launchctl commands to manage Apple services such as smbd file sharing. Due to security reasons, it is unlikely to work properly. Your user account isn't privileged enough despite having local admin rights and even using sudo. You can use launchctl for any services you create but do not use it with Apple default services. There be dragons if you attempt it. I think it has to due with the security of the read-only System volume that boots from an immutable APFS snapshot. When you turn on File Sharing in System Settings you are prompted for an admin account login which elevates and then there's something known as a SecureToken, etc. Suffice to say there is a lot going on when you toggle that ON/OFF for File Sharing.

Undo the launchctl commands you entered. i.e. unload or bootout smbd Then restart the Mac.

Open System Settings -> General -> Turn on File Sharing and click the little i in a circle to the right of the ON/OFF toggle button. Turn ON Allow full disk access for all users. Double-check your users and permissions. Click the Options button and Share files and folders under SMB and under Windows File Sharing check your Account.

Stop trying to mount a share on your local machine Mac. Find another computer you can connect to that has a Windows share. Press CMD + K in the finder.

Syntax:

smb://DOMAIN;USER@HOSTNAME/SHARE/FOLDER

Example:

smb://user@imac.local/

Where user is your short username. You can find your short username by opening Terminal and typing the command whoami.

Where imac is the hostname of the remote computer and the .local will user Bonjour to find the computer without needing DNS.

When you do it that way you should be prompted to connect. Then you will be prompted for the registered user ID/PW and checkbox to save to keychain. Then it will list the shares that are available. Once you connect, open up Finder Connect to Server again and click the + to add it to your favorites.

Tested mapping shares from Sequoia to Ventura and back the other way. It works fine.

I have 'file sharing: on' in system settings, have set up read/write access to my Downloads folder and 'SMB file sharing' is toggled on.

On the server, does smbd have full disk access? That is required if you want to share out from your home directory.

edit: It appears that setting is now in the File Sharing System Settings.

macOS doesn't use Samba. Microsoft doesn't even use Samba. Microsoft invented the protocol and Apple wrote their own SMB implementation.

I have seen toggling File Sharing off/on on the server Mac will get it to work.

If you are using any VPN, Firewall, or other network security software, turn it off and try.

Cochonfou wrote:

Looking around the internet, it seems that this ._smb._tcp.local suffix has existed before Sequoia, so I assume it has been a valid syntax for some time, but that there is currently a bug with the "regular" (and more straightforward) SMB syntax.

Those are Bonjour names. In theory, you can query for more information with the "dns-sd" tool.

You can find all local SMB servers with: dns-sd -B _smb._tcp

You could find the IP addresses of your server with: dns-sd -G v4v6 MyCloud-UT6A4L.local

They still won't work. However, when I tried with the Bonjour address as your describe I could connect to my own server. Curious.

erickdobrasil wrote:

In order to troubleshoot this, I decided to use the mac Finder's 'connect to server' feature on the mac to access itself. This has also worked in the past.

That isn't working for me either. I can, however, connect from a different client.

In System Settings > Sharing > File Sharing, make sure to click "Options" and add your password for your account. I did that and I was able to connect from Linux. I could also connect from a locally running Sequoia virtual machine. Adding the password was not necessary when connecting from a Sequoia VM, but it was required when connecting from Linux.

I don't have any iOS 18 devices to try. I run Sequoia on this test machine because I'm a developer and I have apps that need to support it. But this is strictly my test machine. I'm still running Ventura on my primary computer and my iOS test devices are iOS 15. I'm only running Ventura because of a different Apple developer requirement. I have no idea why so many people are so eager to run these new versions the day they get released. 😄

I've read that Apple's Firewall is causing issues with Sequoia. I have switched mine off and connecting to my NAS over SMB has been working ever since.

Have you tried to mount with Terminal?

mount_smbfs //username@SharedFolder/child ./someFolderForMount

You should be able to have verbose there too.

Just tried on a fresh 15.0 install and it works for my unraid smb share just fine.

Discovery-DNS-SD on the App Store (I think it's free) is a Bonjour live browser. It shows all the devices sending messages to each other.

https://apps.apple.com/us/app/discovery-dns-sd-browser/id1381004916?mt=12

erickdobrasil wrote:

<snip>

I have high regard for Apple and expected their XX.0 release to be pretty bug free.

<snip/>

Been computing for 40+ years... NOBODY RELEASES BUG FREE SOFTWARE on a major new release upgrade. There are always bugs no matter how much you test. This is how vulnerabilities occur which is why we have to constantly patch and update to prevent bad actors hacking. There are possible bugs occurring during installation upgrade. Especially if you skipped any macOS major version. Like upgrading from Monterey directly to Sequoia. That is potentially rolling the dice of chance.

Trust No-One! STEP 1: BACKUP YOUR SYSTEM using Time Machine / CCC / etc. You should have backed up prior to upgrading to Sequoia. If so, just restore your backup and you'll be back to Sonoma like nothing happened.

Have you attempted to re-install macOS Sequoia over the top of your existing Sequoia?

This should be relatively safe because the system volume is entirely read-only immutable except for Apple who holds special certs and signatures only they have. It will only barely touch your Data volume containing your apps and user data.

Open Terminal and run this command, it will create "Install macOS Sequoia" in your /Applications folder.

softwareupdate --fetch-full-installer --full-installer-version 15.0

Then what I recommend is that you boot into Safe Mode before running the installer.

That will ensure no 3rd party services, agents, daemons are running.

Start up your Mac in safe mode - Apple Support

Then launch the installer from /Applications/Install macOS Sequoia and install over the top of Macintosh HD.

Another option to test things would require at least 80GB of free space to dual boot

APFS Volumes will share the total disk space dynamically. No need to set volume size, etc.

1. Open Disk Utility select the View menu and Show All Devices.
2. On the left sidebar click on the Container disk under your Apple SSD.
3. Right-click it and choose Add APFS Volume.
4. Give it name other than Macintosh HD perhaps call it Test
5. Run the installer and choose that new APFS disk named Test.
6. Create an account called admin and set a password do not use your primary account UID/PW.
7. Create another account and this one should mimic your primary account w/same UID/PW.
8. But login to the admin account only.

Note: it's also possible to install to an external disk and boot from that providing your internal SSD containing macOS is working. This is an option if you are low on disk space.

This will allow you to dual boot between the broken Sequoia on Macintosh HD and your Test installation. Boot up in to the Test volume by holding power button during power on. If Intel Mac hold Shift while powering on. Login as the new admin account.

Test Safari with Facebook using your account. If you have the same broken dark mode rendering. Then maybe it is Facebook and your specific account.

You can boot back into Macintosh HD and then open disk utility and safely remove your Test APFS volume.

If things are working on Test, You could mount your other Data volume from Macintosh HD (might already be mounted) and using Terminal, sudo mv / cp your data back over. Include ~/Library. Put the files into your primary user account that you haven't logged into yet. You could also use rsync to copy the files if you know how to use it. Then manually re-install each Application. Most of your data will be intact. Avoid cleaners, security software like antivirus, 3rd party external disk software from WD, etc. For any apps whose data is missing you'll need to figure out where it's stored on the Macintosh HD volume and copy it over. Don't forget about hidden dot filenames in your home directory, etc. Stuff like ~/.ssh/config and ~/.zprofile etc., etc., etc.

Wish you the best of luck!

I don't really understand either adding ".local" or using "joesmith" instead of "Joe Smith" fixes access by Files app using smb.

joesmith is your username for the account. Joe Smith is just a human readable label for the account username. Apple will "label" authentication dialogs with your human readable label, but it is still using your account username in the background.

I have always had to use .local. At some point in the past several years, that used to show up in the File Sharing dialog for how to connect to that server with a hostname.local format. However, all I see now is an IP address.

I have been struggling since upgrading to Sequoia with connecting to a PC server on my LAN. I could access with Remote Desktop (now called Windows App) using the SMB share name but not the server.

I could access the server with the IP address but not the SMB share name.

After reading this I tried a few options and have found that just adding .lan' to the end worked for me.

So instead of using 'smb://XXX-PC' I now use 'smb://XXX-PC.local'

The point is to test SMBD! Because it was not working from a remote system.

I've been using Sequoia for a while and have found SMB connections faster to establish and I haven't dropped any.

I don't use them continuously or daily, but will normally keep one connected for several hours. That is primarily to a Haas Mini Mill over WiFi. There is absolutely nothing doing any network management. I also file share between my Macs and haven't had any issues. Those connections are normally not prolonged.

There are networking changes in Sequoia, so anything you have doing any kind of filtering or redirection may be broken, now.

You should talk directly with Apple. They won't know there is any sort of problem unless a lot of people communicate those problems to Apple.