Mageia Rel 5 16/June Attempting to access shared madia located as USB device on Telstra/Technicolor WAN Gateway/Internal LAN,WAN, and media server. Files on the SMB share are accesible from iphone and android devices (with appropriate 'apps') and from windows clients on this lan. cifs kernel module is loaded. No success so far with MGA5. MCC->Network Sharing -> Configure Windows Shares -> Search servers Correctly identifies the SMB device and share volume on it. Clicking on this device brings up the mount dialogue. Accepting defaults the clicking 'MOUNT' brings up a non-specific message 'Mount Failed'. Journal extract below: mount_part: device=//t-gateway/Disk_a1 mntpoint=/mnt/Disk_a1 isMounted= real_mntpoint= device_UUID= Jun 23 12:04:17 localhost drakdisk[6387]: mounting //t-gateway/Disk_a1 on /mnt/Disk_a1 as type cifs, options username=% Jun 23 12:04:17 localhost drakdisk[6387]: created directory /mnt/Disk_a1 (and parents if necessary) Jun 23 12:04:17 localhost drakdisk[6387]: running: mount -t cifs //t-gateway/Disk_a1 /mnt/Disk_a1 -o username=% Jun 23 12:04:17 localhost drakdisk[6387]: error: mounting partition //t-gateway/Disk_a1 in directory /mnt/Disk_a1 failed at /usr/lib/libDrakX/fs/mount.pm line 87. Trying to do this through Smb4K got no further but threw error (22) - Invalid argument. Reproduce steps: Paragraphs 1-3 above Reproducible: Steps to Reproduce:
Created attachment 6768 [details] journalctl -xb output
Created attachment 6769 [details] Another snippet ....
Comment 2 snippet - not sure if last line is relevant, but shows DHCP reponse from server
Adding some packagers who are knowledgeable about samba and CIFS in CC.
Component: Release (media or process) => RPM PackagesSource RPM: (none) => sambaCC: (none) => bgmilne, shlomif, thomas
I have since been able to access the share's directory with smbclient: [root@localhost etc]# smbclient //T-GATEWAY/Disk_a1 Enter vlad's password: (Null worked here) Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.0.37] Server not using user level security and no password supplied. smb: \> dir . D 0 Tue Jun 2 16:29:15 2015 .. D 0 Tue Jun 23 20:13:50 2015 .mvfs DH 0 Tue Jun 23 20:34:36 2015 .Trash-1000 DH 0 Wed Jan 21 10:25:29 2015 Movies D 0 Mon Jun 1 09:47:05 2015 Photos D 0 Mon Jun 1 09:38:42 2015 System Volume Information D 0 Thu Oct 23 21:23:38 2014 writing D 0 Tue Jun 2 16:30:21 2015 61048 blocks of size 1048576. 16385 blocks available smb: \> cd writing smb: \writing\> dir . D 0 Tue Jun 2 16:30:21 2015 .. D 0 Tue Jun 2 16:29:15 2015 .~lock.Chapter 2.doc# AH 0 Fri Mar 20 10:23:18 2015 Chapter 2.doc A 101376 Sat Mar 21 12:59:28 2015 Chapter 2.odt A 64448 Fri Mar 20 11:26:48 2015 Chapter 1.doc A 117760 Mon Mar 9 11:35:37 2015 Chapter 3.doc A 98816 Fri Mar 27 12:48:10 2015 Chapter 4.doc A 123392 Sat Apr 25 13:21:56 2015 Chapter 5.doc A 99328 Fri May 15 14:21:58 2015 Chapter 6.doc A 138752 Fri May 15 15:30:10 2015 Chapter 6.odt A 72032 Mon Apr 6 15:04:44 2015 Chapter 7.doc A 131584 Wed May 20 13:20:30 2015 Chapter 8.doc A 110592 Thu May 28 16:47:23 2015 Chapter 9.doc A 122368 Tue Jun 2 16:00:32 2015 Final20120716 D 0 Sat May 30 09:15:48 2015 Prologue.doc A 48128 Fri Mar 6 13:56:33 2015 61048 blocks of size 1048576. 16385 blocks available smb: \writing\> get Prologue.doc getting file \writing\Prologue.doc of size 48128 as Prologue.doc (2473.7 KiloBytes/sec) (average 2473.7 KiloBytes/sec) smb: \writing\> q The above shows that the server is accessible, works, and one can transfer files from it to the client using a dos/ftp style shell. While this vindicates components in the chain, it is probably not the best way to access a media server. MCC and SMB4k rely on the traditional way of doing things by trying to mount the remorte share. However, mounting the share has failed in every case that I have tried, with MCC, SMB4k or sambaclient.
I know CIFS mounting works with Mageia 5 as I've done it through pam_mount. You'll need to work with the mount command directly to try to debug this and figure out why it's not working. Maybe some security setting.
Source RPM: samba => cifs-utilsCC: sysadmin-bugs => (none)Keywords: (none) => NEEDINFO
Further testing has shown that the SMB server is immediately accessible and browsable through dolphin, konqueror and Nautilus in KDE, Gnome and XLDE. The common theme is that: MCC-> Network Sharing -> Configure Windows Shares -> Search servers -> mount fails to mount the smb share in every GE. Therefore MCC has a problem with correctly populating the mount command assembled in /usr/lib/libDrakX/fs/mount.pm line 87. The attempted mount statement as put together by MCC is: running: mount -t cifs //t-gateway/Disk_a1 /mnt/Disk_a1 -o username=% '%' seems to be an unsubstituted parameter variable, is probably spurious in this position and likely and invalid value for username. I have renamed this bug report to better describe the nature of this bug.
Summary: SAMBA-Client fails to mount smb shares on LAN. => MCC fails to mount smb share returning non-specific error.CC: (none) => vzawalin1
Assignee: bugsquad => mageiaKeywords: NEEDINFO => (none)CC: (none) => thierry.vignaudSource RPM: cifs-utils => drakx-net
May be useful ... [root@linux-yim0 vlad]# mount -t cifs //t-gateway/Disk_a1 /mnt/Disk_a1 -o username=vlad mount error: could not resolve address for t-gateway: Unknown error [root@linux-yim0 vlad]# mount -t cifs smb://t-gateway/Disk_a1 /mnt/Disk_a1 -o username=vlad Mounting cifs URL not implemented yet. Attempt to mount smb://t-gateway/Disk_a1 [root@linux-yim0 vlad]# mount smb://t-gateway/Disk_a1 /mnt/Disk_a1 -o username=vlad mount.nfs: Failed to resolve server smb: Name or service not known [root@linux-yim0 vlad]#
Last comment really makes me think of bug 14569, "There is no 'wins' entry in /etc/nsswitch.conf under 'hosts' so resolving the host is impossible. Adding 'wins' solves this problem."
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=14569
Modified /etc/nsswitch to be hosts: mdns4_minimal files nis dns mdns4 myhostname wins winbind No improvement. This apart, I think the unsubstituted parameter '%' remains an issue. Trying the same thing with smb4k returns: mount error(22): Invalid argument Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) the corresponding man entry includes: username=arg specifies the username to connect as. If this is not given, then the environment variable USER is used. Therefore, if the parameter passing in MCC is correct, the substituted result should look like: [root@linux-yim0 vlad]# echo $USER vlad [root@linux-yim0 vlad]# In fact, the generated statement continues to look like: mount -t cifs //t-gateway/Disk_a1 /mnt/Disk_a1 -o username=% With wins and winbind included in nsswitch.conf. [root@linux-yim0 vlad]# mount smb://t-gateway/Disk_a1 /mnt/Disk_a1 -o username=vlad mount.nfs: Failed to resolve server smb: Name or service not known [root@linux-yim0 vlad]# mount -t cifs //t-gateway/Disk_a1 /mnt/Disk_a1 -o username=$USER mount error: could not resolve address for t-gateway: Unknown error [root@linux-yim0 vlad]# [root@linux-yim0 vlad]# mount -t cifs smb://t-gateway/Disk_a1 /mnt/Disk_a1 -o username=$USER Mounting cifs URL not implemented yet. Attempt to mount smb://t-gateway/Disk_a1 root@linux-yim0 vlad]# mount smb://t-gateway/Disk_a1 /mnt/Disk_a1 -o username=$USER mount.nfs: Failed to resolve server smb: Name or service not known [root@linux-yim0 vlad]# So I agree that the server address is still no being resolved, although in this case wins and winbind have been added (and windbind is installed, btw) and the parameters in the mount command have been manually cobbled to what the man page seems to say they should be.
The following works! [root@localhost vlad]# mount.cifs //T-GATEWAY/Disk_a1 /home/vlad/z -o ip=10.0.0.137 Password for vlad@//T-GATEWAY/Disk_a1: [root@localhost vlad]# ls z Movies/ Photos/ System Volume Information/ writing/ The USER= (default) substitution happens behind the scenes as it should, and does not have to be done explicitly by default, if the server has no authentication requirements. The '%' left-over unsatisfied parameter is unnecessary and guarantees an error. This has to be the first fix. The -o after the mount point is a must. Just -IP=... won't work. Providing the IP address of the server seems a must from the above. This means the MCC GUI cannot rely on any internal name service translating the server name into an IP address either, unless this is provided in some less obvious place (hosts file? - don't do this). To get here, I did not need to add 'wins' or 'winbind' to nsswitch.conf, but I did install the 'winbind' package before starting to do this. I don't know therefore if this is a dependency. What this also means is that for the MCC GUI to do its job, it has to know the ip address of the server identified. Equally, smb4k could not mount the share untill it knew about the address. There some form of finding the ip address of each smb server found need to be available when the user chooses which share he wants to mount. Still a bit of analysis and coding left, but I hope this helps.
Maybe the "real" Problem is the missing Password-dialog in mcc. I've tried to connect to a sambashare with another user, but there is no Option to give a Password away. In MGA4 the Password-Dialog is still alive and working.
CC: (none) => michael.schuett.lwl
(In reply to Michael Schütt from comment #12) > Maybe the "real" Problem is the missing Password-dialog in mcc. > I've tried to connect to a sambashare with another user, but there is no > Option to give a Password away. > In MGA4 the Password-Dialog is still alive and working. More than likely. MCC seems to try and deal with this mount -t cifs //t-gateway/Disk_a1 /mnt/Disk_a1 -o username=% but gets the syntax wrong. tHE MAN
Continued from comment 13. The man entry states that in the absence of an explicit username parameter the current user is assumed, and the password is requested. The default can't necessarily be used in MCC, because the server may have its own authentication requirements The userid/password dialogue certainly needs fixing.
Summary: MCC fails to mount smb share returning non-specific error. => MCC fails to mount smb share returning non-specific error (missing password dialog, regression from mga4).
Is this bug still valid?
Assignee: mageia => mageiatoolsCC: (none) => marja11Keywords: (none) => NEEDINFO
(In reply to Marja Van Waes from comment #15) > Is this bug still valid? Over a year later and no reply, closing as OLD. Please reopen this report and change its "Version:" at the top left to "6", if the same bug still exists in Mageia 6.
Status: NEW => RESOLVEDResolution: (none) => OLD
As of MGA7 x86_64 May 2020 this bug still seems to be valid. My Telstra Smartmodem Gen 2 has a Seagate 2Tb external drive plugged into its USB port, and made available under Samba. On that Telstra box, I have Samba SMBv2 enabled. In MCC, Network Sharing, Access Windows SMB shares, I see my modem "maybe-modem", and below that, the attached Seagate drive 'SeagateMod' Clicking on the mountpoint tab creates /mnt/SeagateMod as the mount point - and creates it. This then spawns the Mount tab; clicking on this fails: "Mounting partition //maybe-modem/SeagateMod in directory /mnt/SeagateMod failed" that's it - didn't provide any further info. I suspect from the above discussion in this very old bug that the problem remains MCC does not provide a way to handle username and password for the proposed mount. Comment 14 still seems valid. Regards, Tony
CC: (none) => tablackwellVersion: 5 => 7Resolution: OLD => (none)Status: RESOLVED => REOPENED
Still valid?
CC: (none) => fri
Mageia 7 is EOL since July 1st 2021. There will not have any further bugfix for this release. You are encouraged to upgrade to Mageia 8 as soon as possible. @reporter, if this bug still apply with Mageia 8, please let us know it. @packager, if you work on the Mageia 7 version of your package, please check the Mageia 8 package if issue is also present. In this case, please fix the Mageia 8 version instead. This bug report will be closed OLD if there is no further notice within 1st September 2021.
Hi bug reporter and hi assignee and others involved, Please reopen this bug report if it is still valid for Mageia 8 or 9(cauldron), and change "Version:" in the upper left of this report accordingly. This report is being closed as OLD because it was filed against Mageia 7, for which support ended on June 30th 2021. Thanks, Marja
Status: REOPENED => RESOLVEDResolution: (none) => OLD