Bogus RPM.
Either you're using drakwizard or drakxtools(diskdrake)

(In reply to comment #1)
> Bogus RPM.
> Either you're using drakwizard or drakxtools(diskdrake)

I use drakxtools and it use perhaps lsnetdrake.

Pinging, because nothing has happened with this report for more than 3 months, it still has the status NEW or REOPENED.

CC: (none) => marja11

The problem still exists.

If nss_wins is installed, you should be able to resolve 'usbstation', e.g. 'getent hosts usbstation' should return the IP address.

The cifs-utils package, which provides mount.cifs, suggests nss_wins.

Please indicate whether you have nss_wins, and if not, whether installing nss_wins resolves the issue.

Status: NEW => UNCONFIRMED
CC: (none) => bgmilne
Ever confirmed: 1 => 0

Yes I have nss_wins installed.
'getent hosts usbstation' can return the IP only if I write it in hosts !!!
I explained in comment #1 that MCC found a name for the network disk ( I do not know why), I suppose it found also the IP but it use only the name for writing
the line in fstab. But "mount.cifs" cannot work because it need the IP and MCC
has not writed this in hosts.
I know how resolve the problem but a new user of Linux cannot resolve this.

1)By default, we don't want to rely on a static mapping which could be incorrect. So, solutions such as /etc/hosts are not good defaults.
2)Some CIFS/SMB servers, specifically Microsoft Windows, don't support being accessed with the IP as the name, so using the IP address in the share is not reliable.
3)The IP was resolved by MCC using an NMB lookup. If nmbd is running, nss_wins should be able to resolve any name nmbd is aware of.

If, using nss_wins, you can't resolve the name (without /etc/hosts), try:
$ nmblookup usbstation
then
$ getent passwd usbstation

If the first succeeds, the second should. If the first doesn't succeed, then there is some other problem (such as the device does not advertise its name via NMB broadcasts, does not respond to broadcasts, there are firewall issues etc.).

NMB is inherently unreliable, you can improve the situation by using a samba server as a WINS server (and publishing this via DHCP), which will result in more reliable windows host resolution (without any configuration for Windows hosts).

nmbd is not running (I don't need it)
nmblookup works fine and resolve usbstation
I don't understand why "getent passwd usbstation" it don't succed
and "getent hosts usbstation" don't succed.

In fstab can this line :
//usbstation/usbshare /mnt/usbshare cifs username=% 0 0
be resolved if there is nothing in hosts ?

Hi,

This bug was filed against cauldron, but we do not have cauldron at the moment.

Please report whether this bug is still valid for Mageia 2.

Thanks :)

Cheers,
marja

Keywords: (none) => NEEDINFO

This bug is still valid for Mageia 2.

Whiteboard: (none) => MGA2TOO

This bug is still valid in Mageia 3 beta2

CC: (none) => yves.brungard_mageia

Please at least test if starting nmbd (smb service) on the 'client' allows nss_wins to work.

I am not prepared to set up a test of this if the reporter isn't prepared to do a simple 'service smb start' and check if this resolves the issue.

If these remarks are for me:
# service smb start
Starting smb (via systemctl):                                   [  OK  ]
[root@LINUX-AMD-X3 adminpanel]# ps -u root |grep smb
 2933 ?        00:00:00 smbd
 2955 ?        00:00:00 smbd
[root@LINUX-AMD-X3 adminpanel]# ps -u root |grep nmb
 2941 ?        00:00:00 nmbd

The station which shares directories is "Ordi".

$ nmblookup Ordi
querying Ordi on 192.168.1.255
192.168.1.37 Ordi<00>
$ getent passwd Ordi
[yves@LINUX-AMD-X3 adminpanel]$

Sorry, I see had an error above (my fingers are too used to typing getent passwd), it should be:

$ getent hosts ordi

removing "UNCONFIRMED" because papoteur confirmed it in comment 11

Status: UNCONFIRMED => NEW
Ever confirmed: 0 => 1

I try a new test from scratch:
I have a server named (netbios) Ordi at 192.168.1.37
- installing Mga3beta2 with DVD-i586, old /home, but new user
- configuring to access a SMB drive with MCC. Ordi is seen as server, an the directory which is shared is visible.
- declaring a mount point /mnt/ordipost
- trying to mount it : unable
- writing to fstab
# mount /mnt/ordipost
Unable to resolve, unknow error (I have to retreive the exact wording)
# urpmi samba-server
# systemctl start smb.service
The service is running
# nmblookup Ordi
querying Ordi on 192.168.1.255
192.168.1.37 Ordi<00>
$ getent hosts Ordi
nothing

Status: NEW => UNCONFIRMED
Ever confirmed: 1 => 0

The error with the mount command is :
mount /mnt/ordipost
mount error: could not resolve address for ordi: Unknown error

In fstab:
//ordi/ordipost /mnt/ordipost cifs defaults 0 0

again :)

Status: UNCONFIRMED => NEW
Ever confirmed: 0 => 1

Since kernel 3.7 there are modifications for mount.cifs
It seems that mount.cifs does not work.
See bug 7673.

I haven't this problem on Mageia 2.

Excuse me it is on Mageia 3
This bug is still valid in Mageia 3 beta2

This works in Mageia 5 x64. Found windows 7 share using MCC. Nominated mount pount and mounted. Entry from fstab = 

//walter/Users /mnt/Users cifs credentials=/etc/samb/auth.walter.nic,domain=workgroup 0 0

Reboot Mageia and then from command line:
sudo mount /mnt/Users

mount

//walter/Users on /mnt/Users type cifs (rw,relatime,vers=1.0,cache=strict,username=nic,domain=workgroup,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.3.212,file_mode=0755,dir_mode=0755,nounix,serverino,rsize=61440,wsize=65536,actimeo=1)

so fixed

Status: NEW => RESOLVED
CC: (none) => nic
Resolution: (none) => FIXED