Previous 1 3 4 5 6 7 Next 132 Replies Latest reply: Jun 29, 2015 3:24 AM by Ben.Stratton-Woodward Go to original post
  • sysmgr Level 1 (0 points)



    Weird that it's different per machine - I bought my wife a new MBP and immediately upgraded it to Lion, it can access the same shares mine cannot, fine...

  • CDeLorme Level 1 (0 points)

    Going to summarize the problem I had and what I've done to try and fix it.  If it matches yours you are welcome to chime in with other tests, and if I find a solution I will post it.



    First, I have a Windows File Server and am trying to connect from a Mac running OS X 10.07 (Lion).  I just upgraded this afternoon, and so far there has been a mixed bag of likes & dislikes, this is one of the dislikes and appears plain as day to be a new bug in OS X with no documentation.





    The server is working fine, two other computers on the network could connect and not 13 hours before Snow Leopard on this machine was using it to backup files.



    I use the connect-to option in finder, with a standard line:






    This gives me a big fat "There was a problem connecting to the server" error, which says I don't have permissions.  Funny, because I never entered any permissions, it didn't let me.



    I tried entering just the server without the share, and it displays a list of shares on the system (I had never tried it before, so not sure if that's new), but as soon as I select one I am met with the same error.





    The Problem:



    The "Connect To" option is not asking you for your credentials, former iterations of OS X would ask if you were a guest or registered user, and would prompt you for a username and password.  Hence one solution is to add your username and password as a user with access rights to the system managing the file sharing (If the folder is shared by username and not a group you have to add the user, otherwise you need the new user to be a member of the group with shared access rights).



    Obviously adding a new username per machine/user is an unacceptable solution for a business environment, and I doubt it would work on systems with domains (like, only for computer name or ip address.





    It's quite possible we simply aren't "doing it right", which is to say maybe there is some way to specify alternative credentials, but I spent three hours scouring for documentation and couldn't find any from apple or elsewhere.



    At one point I got lucky and spotted my system in finders Network>All..., and was able to access using the "connect as" setting in there, but now it isn't displayed so probably not a reliable workaround.

  • CDeLorme Level 1 (0 points)

    I found a way to get it working via command line.



    As I stated in my former post, Samba is working in Lion, but the UI for it isn't.  When you use the Connect to Server option, it doesn't ask you for your credentials, it automatically assumes your Mac Credentials (username & password), which generally doesn't work.





    Anyways, here is the solution:



    ->  Launch Terminal



    ->  Create a folder, for my test I created a desktop folder

              mkdir ~/Desktop/MyMedia



    ->  Command Line Format to mount the SMB share:

              mount -t smbfs //Username@ServerOrIP/Media ~/Desktop/MyMedia



    ->  A prompt will ask for your password





    Some quirks, terminal will still show the folder name as MyMedia, but the desktop and finder display it as "Media" (the share name).  However, it works, I am in and able to access my shared files.

  • sysmgr Level 1 (0 points)

    I get prompted for credentials when I do this via the gui.


    I also see on the server end that it is using the correct username (ie. the one i enter into the gui, not the Mac ones as you suggest)


    Also, mounting the share manually via the command line still only works for access via the command line for me.


    Glad it's working for you now though

  • Bob Pankratz Level 1 (0 points)

    The actual bug is that Lion is failing to pull the saved username from the Mac KeyChain.

    Instead it is using your mac username.


    Therefore if your mac username is not equal to your server account name; it will fail to mount, if you use saved credentials



    *** Here's the tested workaround we are using.


    1) Do NOT save the user credentials for the network share in the keychain. (If you already did; then use KeyChain program to delete the saved credentials ((search for server name and delete items of type "network password")) )


    2) Change your Finder Cmd-K URLs to include your Network Short username (your NLTM username).








              You can't use UPN network names because the Extra @ symbol will confuse some servers.

               Your mileage will vary if you do:





    3) Finally when prompted for username and password; enter your network password and click OK. Do not save the credentials.

  • CDeLorme Level 1 (0 points)

    Not a UI bug then, but a keychain bug?


    Thing is I already tried emptying my keychain of any related items, and cleared the connection history, and even rebooted the system, and that prompt for credentials still doesn't come back up when I try to connect.  Anymore tips for clearing connect to server save credentials flag?

  • Skazzy Level 1 (45 points)

    I's not a keychain bug either.  This step didn't work for me either. In fact, nothing is working for me.  Seems there are 12 solution to 12 different people...



    There's something seriously wrong (with Lion).

  • LostLib Level 1 (0 points)

    Cross posting from:




    After several full Saturdays and Sundays chasing this down (and about 300 restarts), I have my Windows to Apple SMB Share connectivity issue narrowed down and worked around. This applies to OSx 10.7.0 and 10.7.1 on a MacMini (7/2011 Server w/SSD) with Shares under SMB, being connected to by Windows 7.


    Basic Environment:



    1) you restart OSx and your Windows systems CANNOT connect because you get a prompt for userid/password or a not accessable message AND

    2) after 2 or 3 minutes you can Start and Stop SMB Sharing with either (File Sharing) or Preferences/Sharing/File Sharing/Options/SMB on/off (individual IDs do _not_ have to be turned on / off) AND

    3) the userid and password are exactly the same on both the client (Win7 or OSx) and the Sharing system AND

    4) then Windows sytems can connect


    Then the problem is a Race Condition in the Services Startup of OSx. The SMB service is dependent on some security process (guessing) which is completely late in the startup cycle.


    You can test this with the following commands in a terminal window (AFTER the system is up and quiesced):

    sleep 60

    sudo serveradmin stop smb

    sleep 5

    sudo serveradmin start smb


    After talking to Apple Enterprise Support to confirm the issue, I moved the above commands into a launchd script as a work around (this is NOT recommended unless you know what you're doing). Note the initial 60 second sleep - 30 seconds was not long enough. This has been filed with Apple Enginering, they'll figure out what to do about it going forward.


    Part of my problem, is that I'm on a new MacMini (7/2011) which boots from local SSD, it just boots up too fast. If you're on a slower older system - this should not be an issue.


    Some other things which I learned on this journey:

    1) Do not use unload/load of the SMB plist - that does not work for this issue

    2) OD accounts do not work. Wish they would, they dont

    3) Hacking the windows registry as in previous versions to support the previous Samba SMB release (10.6.x and lower) is NOT the problem with any 10.7 release. OSx 10.7 Supports SMB2, as does Vista and Win7.

  • BC2010 Level 1 (5 points)

    jan78 wrote:


    A Solution for mounting Lion SMB Shares from a linux client.

    (I'm using an ArchLinux with Samba 3.5.10-1 and cifs-utils 4.9-3, but it shouldn't matter)


    mount.cifs needs the additional options "nounix,sec=ntlmssp"


    i.e. mount.cifs // /mnt/test/ -o user=******,password=******,nounix,sec=ntlmssp


    I was getting the following:


    WARN [negotiate.cpp:266] SMB client not supported - Unicode, NT Errors, Long Names and Extended Security are required


    And then I tried adding "sec=nltlmssp" to my mounting options and went away.


    HOWEVER, I still get the following from "/usr/sbin/smbd -debug -stdout"

    smb1_dispatch_one [smb_dispatch.cpp:377] dispatching SMB_COM_NEGOTIATE

    socket_look [unix_socket.cpp:285] socket_look: rdsz 0 ---> EPIPE


    Anybody else hit this and getting anything similar?  I'm guessing my EPIPE is the problem.  I even tried "/etc/init.d/iptables stop" on my Linux box to open up the firewall, but this was to avail.

  • mcklveen Level 1 (0 points)

    My work around was to add the login credentials prior to the share name.


    Here is my example.




    Hope this helps everyone.

  • Mangousta Level 1 (0 points)

    GREAT U get the answer cause Seven using his how PC domain so When we want to connect to a lion Server just need to enter user@domain   and the password and it works!!!!

  • kkausu Level 1 (0 points)

    Hi, I have Active Directory on Windows Server 2008 with DFS file share, some Windows and some MAC computer. Till 10.6 using dfs via finder cmd+k and smb://server/share works fine for all user.


    Now with LION my Windows-Admin-Account works still fine. No problem.

    BUT if I login with another account (maria) with less rights I got errors on some shares. I find out that maria has no read right for the root folder on the problem-shares.


    OK-Share:          maria has at least read right on the root folder! ( Traverse folder / execute file )

    Problem-Share:   maria has only the following rights on the root folder.

                             List folder / read data, Read attributes, Read extended attributes.

                             For some subfolders has maria of couse more rights.




    We use this settings, because nobody should see folders where he/she have no access rights. With other words everybody see only the folder where he/she has access rights and the other folders not.

    Till Lion a good solution ;-)


    Now I map the share ( with errors ) and Finder can´t access the share. But with Terminal or muCommander I can access all sharefolders.


    Hope Apple bring a fix soon.



  • Skazzy Level 1 (45 points)



    I've been in email discussion with Apple bug report and after submitting error logs, dump files from Lion and SL OS running Macs from my workplace, they finally reported that it is a known bug.  Let's hope it gets fixed.

  • Jagoan Level 1 (0 points)

    I create a user account named "user", login with that user name. Hopla, it will bring me a user and password dialog box. Fill it with active directory account and it works!

  • john-mac Level 1 (0 points)

    i have this problem too, but only to one 2008 r2 server.  i installed 2 new servers (different sites) they have the same firewall rules, same sp level same updates etc.


    i can connect to both via smb on the lan but cannot talk to one of them when on the vpn.


    i have tried mounting via terminal and also the smb://user:pass@server/share but does not work, i only get the error;


    there was a problem connecting to <server name>

    the server this file server will not allow any additional users to log on


    connecting with 10.6 / xp / win7 via vpn is fine, it is just 10.7 lion with the problem (10.7 / 10.7.1 / 10.7.2)


    i have tested this via mucomander and working ok, but dont really want to get users to use it they want to use the mounted drives on the desktop.

Previous 1 3 4 5 6 7 Next