Posted on 10-29-2013 04:11 AM
Encountered an interesting one during our pre-release testing: SMB2 to some of our server shares doesn't work properly. Mounted a known working share on 10.8 and it works there. Try the same thing again on 10.9 and it can't navigate or see folders down from the root folder.
However if you force 10.9 to mount the drive by using cifs://server.address/ which gets 10.9 to mount the share as SMB1 it works!
The only way round this that i've found is the following code:
# Create nsmb.conf file temporarily and tell it to force SMB1 use.
echo "[default]" >> ~/Library/Preferences/nsmb.conf
echo "smb_neg=smb1_only" >> ~/Library/Preferences/nsmb.conf
The catch is i've only made this work on a per user basis, rather than over the entire computer. Hopefully this will help anyone else having issues.
Solved! Go to Solution.
Posted on 10-29-2013 04:13 AM
D'oh! I should have written the same file to /etc/nsmb.conf instead ...
Posted on 10-29-2013 04:13 AM
D'oh! I should have written the same file to /etc/nsmb.conf instead ...
Posted on 10-29-2013 05:46 AM
Hi Franton,
We are faced with the same problem.What is the steps in getting this code added to run automatically?
Thanks
Posted on 10-29-2013 05:52 AM
Make a policy, go to the advanced tab, add the following to the Run Command:
echo "[default]" >> /etc/nsmb.conf ; echo "smb_neg=smb1_only" >> /etc/nsmb.conf
Posted on 10-29-2013 06:22 AM
Actually that just failed for me. I'm going to try scripting it instead.
Posted on 10-29-2013 06:57 AM
double post!
Posted on 10-29-2013 06:57 AM
Thank you i will keep an eye out for this, more info here http://www.zdnet.com/mavericks-smb2-problem-and-fixes-7000022519/
Posted on 10-29-2013 07:17 AM
It's more than "buggy" – in certain environments Mavericks machines bound to AD can wipe out file/folder permissions or even delete files by changing permissions.
See https://groups.google.com/forum/#!topic/macenterprise/B0R5-WTGIrM for some more info.
We have shares on a NetApp and I've reproduced the problem on AD-bound Mavericks boxes. Clicking any "custom" permission in the Get Info window will wipe out the server-side permissions.
Posted on 10-29-2013 07:56 AM
definitely seeing permission problems on 10.9 with my linux server, I cannot turn off execute bit on the group setting to save my life on the Mac, go to the linux box and i can turn it off. sometimes my vi sessions hang on the smb share too. of course i had to type this reply in Safari because Firefox cannot scroll down most of the time so smb is just one of many problems.
Posted on 10-29-2013 08:36 AM
or simply connect cifs:// instead of smb://
Posted on 10-29-2013 09:14 AM
Apple worked with Microsoft to implment cifs (aka smb2)
Because ive used Thursbys ADmitMac in the past, mount shares as cifs:// i didnt notice the problem.
My guess is that Apple will just come out with a kb soon telling people thats how to connect now rather than messing with the OS.
Posted on 10-29-2013 12:29 PM
Not an option from the command line.
Apple needs to not only FTFF but FTF networking.
Posted on 10-29-2013 11:13 PM
Yep no command line option for cifs welcome to my world ;) only way at the moment is to mount via Applescript
Posted on 10-30-2013 06:50 AM
Or if you need SMB2, you generate that nsmb.conf file on the fly, do what you gotta do and then delete the file. Either way … YUCK.
Posted on 12-19-2013 06:19 AM
May I ask a little question on the side ? Sorry for that, but you all seem to use SMB for Fileservices and are the Pros for that topic.
We use Windows2012R2 as Fileserver and I encounter a misinterpretation of ACL Permissions when copying files to the SMB Share. Especially the Userhome ACL "everyone deny delete" becomes strange on Windows. I get a unknown User-Account/Mode S-1-5-88-3-16832 or S-1-5-88-3-422 or S-1-5-88-3-xxx with a Deny rule. I tried to change access rights like suggested in http://serverfault.com/questions/498171/osx-10-8-3-creating-editing-files-on-windows-7-share-creates-weird-blocking-acco without success.
Sometimes (not always- I love IT) these weird permissions block access to the files and nothing is working properly.
I am coming to the point: Do you have a simple solution or do you use ExtremeZ-IP or AdmitMac or do you go with Helios or Synology Hardware?
Posted on 08-24-2015 04:36 PM
Does everyone still see these SMB2 issues in 10.10.x ? Or was it fixed there ?
Also @michaelhusar we too have also seen that unknown account s-1-5-88-3-16832 with a deny. No idea what that is about.
Posted on 08-28-2015 03:56 PM
There is another thread that very much relates to this one.
https://jamfnation.jamfsoftware.com/discussion.html?id=11266
@jake.snyder Posted the solution below to force the connection to SMB1. I've tried it on individual machines via terminal and it works great. I haven't tried putting it in a script yet to push onto machines.
We are also still seeing the issue where once a machine does a sync it applies that unknown account s-1-5-88-3-16832 with a deny rule. The next time that user tries to log in problems occur. I have no idea what that is about. We are seeing the SMB and this other s-1-5-88-3-16832 issue on 10.10.4 and 10.10.5 clients.
@jake.snyder's solution post :
Apple engineering provided me with a solution today. I have Windows 2008 R2 with SMB shares and my macs are running 10.9.4 and bound to AD.
My environment seems to be working with Access Based Enumeration off and forcing SMB1 on each client.
In order to enforce SMB1 on a mac client:
Create the Global Config:
$ sudo -s
$ sudo echo "[default]" >> /etc/nsmb.conf
$ sudo echo "smb_neg=smb1_only" >> /etc/nsmb.conf
Restart the OS X Client
create a new AD Test user
Login and check if the issue still persist
See the end of Jamf thread 10168 for more details.
Posted on 09-25-2015 05:38 AM
Is there a way to implement this on the machine level rather than per-user? We have a lab that I need to use this fix on.
Posted on 09-25-2015 06:57 AM
Using the following has worked for us in under Mavericks:
sudo sh -c "echo '[default]' >> /etc/nsmb.conf; echo 'smb_neg=smb1_only' >> /etc/nsmb.conf"
Yosemite has worked with the same command, but we've found SMBv2 to work properly.