0

On my ubuntu server i have a few shares that I can access from finder in the style:

smb://server.domain/share

successfully without having to type in a password. When I try to mount the server shares from the command line with:

mount_smbfs '//share;user:@server.domain/share' /Volumes/share

I get

mount_smbfs: server rejected the connection: Authentication error

If i mount one of the shares from the finder all others can be mounted from the command line without this error to appear.

I searched the different stackexchange sites and found the following releated questions and links:

Most of these have a few thousand views and quite a few upvotes. Most interestingly I found two comments where users express the frustration about this issue not being solved in a consistent way.

On the other hands there are lots of downvotes for answers and some of the questions - it seems as this problem is very well known and some enlighted users think it is very clear what to do.

Since this issue is annoying me daily I am daring to ask the question again with the specific context of Ubuntu 16.04 LTS and Mac OS High Sierra 10.13.6.

I fear that answers of the past do not work in this context any more.

The reasons I am asking the question in the first place is that the SMB connections get "lost" over night. This is a different behavior then on my other systems. The CIFS connection between my Ubuntu machines stay stable over time while Mac OS seems to have some disconnection policy.

So my issue could either be solve by making the connection stable or re-establishing the connection automatically with a script

How can a permanent or automatically-script reconnected SMB connection between a Mac OS High Sierra 10.3.6 client and an Ubuntu/Linux SMB server achieved?

1

According to its man page, mount_smbfs takes its share point argument in the form:

//[domain;][user[:password]@]server[/share]

Note the "user[:password]" part -- the colon and password are in the same brackets, indicating that they're optional but if included, they must be included together. Essentially, if you include the colon, whatever's after it (up to the "@") will be taken the password. But you have nothing after the colon, so you're explicitly specifying a blank password.

Also, the man page says you should never run mount_smbfs directly, but instead use mount -t smbfs.

You need to either include the password explicitly, like this:

mount -t smbfs '//share;user:password@server.domain/share' /Volumes/share

Or leave off both colon and password:

mount -t smbfs '//share;user@server.domain/share' /Volumes/share

...in which case it'll look for a password in ~/Library/Preferences/nsmb.conf, and if it isn't there it'll prompt for one. I had thought that it could look in the keychain, but apparently it doesn't know how to do that. This means that there is no non-interactive, secure way to supply a password to mount_smbfs.

Depending on the context this is running in, you might be able to use the open command instead:

open 'smb://share;user@server.domain/share'

I think this'll need to be running in a user session, and doesn't give you control of the mount point (it'll be auto-created in /Volumes).

Oh, one other thing: the "share;" part of the URL specifies an authentication domain to find the user in. Is that part actually correct? If it is, the open command should work interactively.

  • Thank you for pointing this out. Having the password on the command line is the insecure version I abandoned many years ago. I do not want to go back to this state. The keychain version is what does not work - please try it out yourself. I'd appreciate if you'd remove your answer since it does not help at all and I do not want many downvoted answers again. – Wolfgang Fahl Nov 4 '18 at 5:48
  • 1
    @WolfgangFahl See update. – Gordon Davisson Nov 4 '18 at 6:10
  • Thx for the update - I'll look into this on another day when the network connection drops again – Wolfgang Fahl Nov 4 '18 at 6:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .