I don't know that upgrading to 10.8 should be seen as any guarantee to fix the issues that some - not all - are having.
I will say that I did a clean install of 10.8.2 server (always avoid ugprade installs whenver & wherever possible, regardless of platform) and with a stock install (but configured with proper DNS), Windows 7 PCs can connect to the smb shares just fine.
I haven't had an issue mounting smb shares on the Mac. Mounting smb shares on to Windows 7 is severely broken as msft has invented some new home sharing bs that breaks everything, unless you use their new methods, nothing seems to work. I can't get smb shares to work properly between W7 and XP either.
I didn't check all 9 pages of this thread (so this may already have been mentioned), but after beating my head against the desk for a day, I found this.
It 'fixed' the problem for me.
Hello from Switzerland
I have the problem outlined in this thread. Exept that a lot of it I do not understand. When it comes down to the command line I'm lost. Also, my knowledge of Windows is small, I'm quite good on the Mac.
I'm running Windows 7 Pro on a MacBook Pro (10.7.5). My server is installed on a Mac Mini (mid 2011), running Lion server 10.7.5.
Can someone summarize all the above and put it in a way I can understand.
Thanks in advance for your
I have a slightly different problem; OSX Lion Server 10.7.5 binded to AD (2008 server)
There is storage attached to the mac server, i created a couple of shares for it.
I gave Active Directory groups acces rights on the shares that I created on the Lion Server.
I have 60 mac clients which are all working fine connect on their mac to the shares on the Lion server with their AC accounts.
So far so good, now there are a couple of Win7 users who need to access the shares as well.
Initially I cannot connect from a Win7 machine to the share on the Lion Server.
But when i (once) make the connection on a mac with the account of the user, then go back to the Win7 machine i CAN make the connection. this works until i reboot the server, then the connection is lost and it will not be possible to connect again until i authenticate via a mac client to the share..
Anyone an idea?
Works perfectly on 10.7.5 server! Thanks.
here's what i did to fix it...
temporarily disable the SMB service, then re-type your user account (MacOS) password (that Windows clients are using to authenticate on your Mac)
- System Preferences > Sharing > File Sharing > Options button
- UNCHECK 'Share files and folders using SMB'
- UNCHECK the 'On' box next to the user account(s) to which Windows clients will be authenticating
then, do the reverse:
- re-check the 'On' box for each user account, and RE-ENTER the password(s)
- re-check the box 'Share files and folders using SMB'
- click DONE
I will repeat this again for a very simple solution to this problem for all those that do not want to get into command line hokey-pockery:
THE EVEN SIMPLER SIMPLER SOLUTION.
Install a free Samba 3 SMB file sharing system solution.
Grab an app called SMBUp, which will fully automate the install process. (Its fully reversible too!)
Thank the Author too.
Its a Godsend!!!
I have a similar problem: I have a NTFS formatted USB Drive, mounted on my macmini using NTFS-3G.
Macmini is a 2.5Ghz i5, running OS is OSX 10.7.5.
I share on SMB several Mac folders, some placed on MacHD and one placed on the NTFS Drive.
I can access flawlessly all the folders located on MacHD, while cannot open the folders on NTFS Drive.
I have tried all I could find, disabling and enabling sharing and username under Mac's sharing preferences, using the secpol.msc settings and the regedit trick under win7, but I still cannot connect to the NTFS mac-shared folder.
I am starting to think the matter is it's a ntfs drive, indeed, since I can connect to MacHD shared folders.
Kerberos log states:
2013-10-01T22:24:25 digest-request: od failed with 2 proto=ntlmv2
2013-10-01T22:24:25 digest-request: user=MACMINI\\John
2013-10-01T22:24:25 digest-request kdc: ok user=MACMINI\\John proto=ntlmv2 flags: NEG_KEYEX, ENC_128, NEG_VERSION, NEG_TARGET_INFO, NEG_NTLM2, NEG_ALWAYS_SIGN, NEG_NTLM, NEG_SIGN, NEG_TARGET, NEG_UNICODE
IIRC, the NTFS-3G (free) has some limitations on mounting block devices.
This is from the NTFS-3G FAQ
Unprivileged block device mounts work only if all the below requirements are met:
- ntfs-3g is compiled with integrated FUSE support
- the ntfs-3g binary is at least version 1.2506
- the ntfs-3g binary is set to setuid-root
- the user has access right to the volume
- the user has access right to the mount point
The root user can make an ntfs-3g binary setuid-root as shown below
chown root $(which ntfs-3g)
chmod 4755 $(which ntfs-3g) In such case the driver will also be able
- to fix common FUSE kernel module loading problems
- to create the required but sometimes incorrectly removed or missing FUSE device file
Please note that using setuid-root can result unforeseen privilege escalation and its usage is discouraged. Only the absolutely trusted users must be granted such access. Below is an example how this can be done for users in the ntfsuser group to be able to mount any NTFS volume if they have also the needed volume access rights. chown root.ntfsuser $(which ntfs-3g)
chmod 4750 $(which ntfs-3g) The setuid-root ntfs-3g driver applies the principle of least privilege during its lifetime as a safety measure.
Thanks for helping me fix this. I have a Xserve runinng OS X 10.7 Lion Server that was a clean install, not an upgrade. A user got a new computer with Windows 7 and could not connect. I did the following.
1. System Preferences > Sharing > File Sharing > Options > Unchecked Share files and folders using SMB
2. Deleted the users Open Directory account using Workgroup Manager
3. Recreated a new Open Directory user account using Workgroup Manager.
4. Checked Share files and folders using SMB.
On Windows 7 I was now able to login as the Open Directory user and see the correct sharepoints.
I migrated my XLS files from Windows 2003 to OS X 10.9.2 with clients accesing it from Win 7 logged on to this server.
Strange things are happening viz.
1. If the client is idel for a long time then the client has to relog with authentication?
2. If any XLS file on OS X is opened by a client then it locks it. After which it will always give a message that the file is read only? I have made a work arround i.e. I save it with a different name but i am unable to delete the original file as I geves this message...
"The operation cant be completed becouse the item "****" is in use"
Can anybody let me know how to overcome this issue?