After update on 7.18 my SMB shares stopped successful authentication when accessed from any Linux Mint, OSMC, Android, iPhone, iPad, GoogleTV. It prompted me to enter the username and password, but never went through to the directory content and always asks for inputting the credentials. However it still works from Windows 10/11. Invested several hours into troubleshooting without any luck. Decided to downgrade back to 7.16.2 and it worked right away. Mikrotik team , please take a good look on the new SMB implementation which you mark as smb - stability improvements for client/server, cause in reality it worsens the experience somehow.
Agreed!
Just tried to set a share up using MT’s own YT video, and nope wouldn’t work.
Turns out you can not even name a share now. You can using terminal, but it is nowhere to be seen in winbox or even when you print /ip/smb/share in terminal.
Whatever you did MT, please fix it ASAP.
Cheers.
Using rOS 7.18.2
I had the same issue but i think its related to capital letters in the shares name (havent tested it though)
Creating a new share without capital letters worked fine.
Havent opened a ticket as i was too lazy for a closer look
This is a user forum
support@mikrotik.com
Thanks, I’ll give it a go tomorrow.
Still a bug though if it doesn’t recognise Caps the name though, right?
Yes, it was also working in a previous version
Is there a chance that they’ve turned on Case Sensitive names for SMB shares? I dont run any to test, but another Linux project I work on had issues lately when they inadvertently turned on this feature in an upgrade. Many people didn’t realize they had been depending on the names of the shares on each side being reduced to lower case.
I’m not sure what going on here, but whatever they did in 7.18 has some bugs IMO.
I have different problem. Since 7.18beta, SMB access from macOS Sequioa to an RB1100AHx4 crashes the entire router. macOS prompts for credentials, and then I hear the router reboot. No supout.rif is generated. IMO NO SMB client should cause ever be able to crash the router, which tell me there is at least one unresolved bug, introduced in 7.18beta2.
And the reboot in 100% reputable in every build from 7.18beta2 → 7.19beta6. What’s odd is it’s just macOS Sequoia that crashes RouterOS. Using Ubuntu 22 and older Mac worked without causes a crash. I opened SUP-177381 case open 2 months, but Mikrotik hasn’t been able to repo my issue.
Anyway, you may want to open a case with Mikrotik, make sure to include a supout.rif. I’m pretty sure your right there is a bug introduced in 7.18.0, whether its same as mine IDK… but I suspect there are breaking changes in 7.18+. Or at least from my POV, since if a macOS SMB client can cause a router reboot under ANY circumstances, that opens the door to a DoS or other attacks.
So i just tested something.
When I recreated the shares, even tho I add it with an uppercase letter it does work on Fedora 41 using kde.
Maybe this is related to sambas weird “password” issue?
Sometimes samba just seems to “forget” the password after an update.
Things like this. I remember I had this issue with a fedora hosted samba server years ago and a password reset helped.
https://askubuntu.com/questions/653924/samba-keeps-asking-username-and-password-whatever-i-do
https://superuser.com/questions/1801983/samba-shares-wont-accept-my-credentials-with-ubuntu-22-lts-windows-10
I’ll try to test that too. Do you have a specific sequioa version?
But since my mac is ancient ill have to run opencore ^^
EDIT: I have ROSE installed. Which is supposed to come with a “better” smb server from what i remember.
But maybe this has changed in some version
One thing to try is disabling encryption for testing. In my case, that didn’t make a difference…but worth a shot, just to see if that works.
I can only repo using these two Mac’s:
2019 MacBook Pro 15.3.2
2020 MacBook Air 15.3.2
(and when I first reported it was running ~15.3.0 or 15.2.x)
Older Mac mini doesn’t crash. Ubuntu 22 and Ubuntu 24 also work without crash. I’ll need to find old laptop with Windows, so far it just macOS 15.x. I went through a quite a few tests, including disabling everything, ensured all short/lowercase path/files, simple user/password, etc. etc.
Now perhaps BOTH Mikrotik and Apple updated stuff, which broke something. Perhaps some security fix in SMB that creates compatibility issues?
I just tried my 2008 Mac Pro 3.1 with 15.3.2 and i noticed the following:
All my shares seems to have been duplicated with caps and without.
But the arm64 hap ax3 didn’t crash when connecting. Sadly, the only other MTs I currently have here with arm32 are cap acs 
Off-topic:
15.3.2 on a single Xeon X5842 (dual cpus are broken with 15) without a Metal GPU is quite a struggle ^^
EDIT: i got one interesting thing.
It wont let me copy any file from the share
Through terminal seems to work tho. Weird thing
Friends, has anyone managed to figure out the problem and solve it or get an answer from technical support?
As a result of my research of the problem I found out the following:
When I create a folder on the disk using file/add it is created with 644 rights and after that I configure it as a shared folder which is accessible via SMB from the Linux-client and the Windows-client.
If I create a folder on the disk via SFTP it is created with 700 rights and such a shared SMB folder returns an authorization error in the Linux-client, while the Windows-client continues to work with it.
All my existing folders are created on disks with 700 or 755 rights and before the update they were accessible via the Linux client, and after the update access from Linux returns an access denied error.
Now I don't know how to change the rights on folders and files on disks via RouterOS or should MikroTik fix the operation of the SMB server?
In the end, I solved the problem. I removed the initial / in the path to the folder in the shared folder settings, i.e. when the folder is written as usb1-part1/nas, the shared folder does not cause problems in the Linux-client, but if the path is written as /usb1-part1/nas, such a shared folder will only work in the Windows-client. This initial / in the path remained from the old RouterOS configuration, before the update to version 7.18 everything worked in Linux.
Brilliant! You have saved me not only time, but also mental health.
My Synonogy log was "Host [xx.xx.xx.xx] failed to connect via [SMB] due to [SMB1 not permitted]." It couldn't help