Bug 984676 - Command line cifs mount failing with "Unable to find suitable address."
Summary: Command line cifs mount failing with "Unable to find suitable address."
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 19
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jeff Layton
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-07-15 16:31 UTC by John William
Modified: 2014-06-18 07:43 UTC (History)
9 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2013-10-08 16:54:27 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description John William 2013-07-15 16:31:44 UTC
Description of problem:
Just did a clean install of F19 (from F18) on this machine. F18 installation connected to a CIFS share on a Win7 machine. Same command line mount now fails on F19.

It is possible to connect to the share and browse files from the File Manager (on F19). "smbtree" also shows the machine and the share I am trying to connect to.

Here is what is happening:

On F18:

[root@localhost <userid>]# mount //<machine-name>/Users/<userid> smb -t cifs -o sec=ntlm,user=<userid>,uid=<userid>

Succeeds and mounts the share in the smb directory.

On F19:

[root@localhost <userid>]# mount //<machine-name>/Users/<userid> smb -t cifs -o sec=ntlm,user=<userid>,uid=<userid>

Fails with "mount error: could not resolve address for <machine-name>: unknown error".

[root@localhost <userid>]# mount //10.0.0.1/Users/<userid> smb -t cifs -o sec=ntlm,user=<userid>,uid=<userid>

Fails with "Unable to find suitable address".

This was a clean install of F19 with no packages added or removed,


Version-Release number of selected component (if applicable):
kernel-3.9.9-302.fc19.x86_64
libsmbclient-4.0.7-1.fc19.x86_64
gvfs-smb-1.16.3-2.fc19.x86_64
cifs-utils-6.1-1.fc19.x86_64

How reproducible:
Always.

Steps to Reproduce:
1. See above.
2. Command line mounts always fail. File Manager mounts seem to always succeed.
3.

Actual results:
Unable to use command-line mounts.

Expected results:
Command line mount to work as it did in F18.

Additional info:

Comment 1 John William 2013-08-31 02:25:08 UTC
It looks like this is related to other Fedora changes in the distribution. Adding IP=xx.xx.xx.xx to the mount command line seems to allow the mount to proceed normally.

Comment 2 Jeff Layton 2013-09-16 13:31:59 UTC
Is this still a problem with more recent kernels? If so, can you retry the mount command with the '-v' flag and post the output here?

Comment 3 Josh Boyer 2013-10-08 16:54:27 UTC
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.

Comment 4 whit 2014-05-30 15:50:40 UTC
I'm seeing what looks like the same thing on Fedora 20.

[root@fedora mnt]# mount -t cifs //192.168.1.27/XYZ /mnt/tmp -o user=someuser -v
Password for someuser@//192.168.1.27/XYZ:  *******
mount.cifs kernel mount options: ip=192.168.1.27,unc=\\192.168.1.27\XYZ,user=someuser,pass=********
Unable to find suitable address.

This is a mount that works fine the same way on CentOS and Ubuntu systems.

Also, it works elsewhere giving the domain name rather than the IP, but here:

root@fedora mnt]# mount -t cifs //ZYZ-S05.abc.local/XYZ /mnt/tmp -o user=someuser -v
mount error: could not resolve address for XYZ-S05.abc.local: Unknown error

which is a strange error since the address resolves fine:

[root@fedora mnt]# dig XYZ-S05.abc.local

...
;; ANSWER SECTION:
XYZ-S05.abc.local. 3600    IN      A       192.168.1.27
...

This is kernel 3.13.9-200.fc20.x86_64.

What, by the way, is a "suitable address" in this context?

Comment 5 Josh Boyer 2014-05-30 16:17:59 UTC
Please open a new bug, but before you do please try the 3.14.4 update in F20 updates stable.


Note You need to log in before you can comment on or make changes to this bug.