Description of problem:This is a problem concerning the mounting of SMB drives, through the facility in the Mageia Control Centre, under "Access Windows (SMB) shared drives and directories" In older versions of Mageia, details input to the devices found, included username and password, which were added to the details in /etc/fstab. A minor problem was that the search in the share setup, found the drive name, but not the address, which fstab required. editing the /etc/hosts file got round that. later in Mga5, a change was made to conceal the device password, readable in clear in the older system, by a new system which might be referred to as the "credentials" system, which created the required files and changes. Oddly, this seemed only to refer to the 32 bit version. I think, at the same time, in the shares setup, for 64 bit systems, the option for entering a password disappeared, which resulted in an etc/fstab file that did not work. Luckily, the 32 bit system could be copied to a 64 bit machine and worked. Now, in Mga6, the option remains without the option for password entry, and the "credentials" option is no longer available. So, mounting the NAS units is a much more complicated system than in Mga5, and requires that the the user has knowledge of the device password(s), and root access. A further problem arises, that the "Search for new servers" facility no longer finds the two Drobo units (Drobo-fs and Drobo N5), but locates the Connected Data Transporter without fail. Whereas, in Mga 5 there was no such problem. It may have been tardy in locating the drives, but they would eventually appear. This is not a breaker, since I can probably use the required entries from a machine still running Mga5, but it is an annoyance. I no longer have 32 bit machine to compare, so these observations are just for 64 bit machines. It is all the more galling since Windows, on the one machine that carries it, has no problems. Logically, perhaps, since the Drobo was designed for use on Windows, but lately, I find that my Android 'phone similarly has no problems with any of by SMB shared systems, in both reading and writing, Whilst my Mageia machines are read only, requiring root operations to write. Which seems to have resulted in a degree of flak on the Mageia Forum, in my search for a root operation for Konqueror in the KDE5 version. In order to move files and such to the NAS. Version-Release number of selected component (if applicable): How reproducible:At all times Steps to Reproduce: 1.Open Mageia Control Centre 2.Navigate to Access Windows (SMB)shared..... 3.Setup Mount Point and Options 4, Create fstab file(s)
Source RPM: (none) => drakxtoolsCC: (none) => marja11, pterjanAssignee: bugsquad => mageiatools
I thought that I'd go through the whole procedure, from scratch, whilst looking into all the details. Since the "search servers" function bought up only the Transporter, out of the three. I'd start with that only. The whole procedure for creating a mount went through as normal. I'd created an entry in /etc/hosts for the Transporter as in Mga5. In the absence of a password entry. I'd have anticipated a request for the password, as in the past, on entering the command 'mount -a'. This failed with the following return, with the results of further commands to clarify and confirm the result. I hope this helps, since the inability to mount my main storage is putting a bit of a crimp on my migration to Mga 6. A copy and paste of the dialogue follows:- [root@think420 rod]# mount -a mount: wrong fs type, bad option, bad superblock on //transporter/Transporter, missing codepage or helper program, or other error (for several filesystems (e.g. nfs, cifs) you might need a /sbin/mount.<type> helper program) In some cases useful info is found in syslog - try dmesg | tail or so. mount: none is already mounted or /proc busy [root@think420 rod]# dmesg | tail [ 39.833031] IFWLOG: register target [ 81.314323] Bluetooth: RFCOMM TTY layer initialized [ 81.314329] Bluetooth: RFCOMM socket layer initialized [ 81.314334] Bluetooth: RFCOMM ver 1.11 [ 1925.935475] Unable to determine destination address. [ 1925.935629] Unable to determine destination address. [ 4003.542702] Unable to determine destination address. [ 4238.235033] Unable to determine destination address. [ 4330.112296] Unable to determine destination address. [ 4378.655016] Unable to determine destination address. [root@think420 rod]# more /etc/hosts 127.0.0.1 localhost 127.0.0.1 thinkpad 192.168.1.150 gateway 192.168.1.200 down downstairs 192.168.1.202 up upstairs 192.168.1.204 bluey bluebook 192.168.1.210 red redbook 192.168.1.213 netbookwifi 192.168.1.214 netbooketh 192.168.1.190 laserjet1 192.168.1.192 laserjet2 192.168.1.154 drobo-fs 192.168.1.156 Transporter 192.168.1.158 drobo5n [root@think420 rod]# ping 192.168.1.156 PING 192.168.1.156 (192.168.1.156) 56(84) bytes of data. 64 bytes from 192.168.1.156: icmp_seq=1 ttl=64 time=1.42 ms 64 bytes from 192.168.1.156: icmp_seq=2 ttl=64 time=5.51 ms 64 bytes from 192.168.1.156: icmp_seq=3 ttl=64 time=2.52 ms 64 bytes from 192.168.1.156: icmp_seq=4 ttl=64 time=1.61 ms 64 bytes from 192.168.1.156: icmp_seq=5 ttl=64 time=1.72 ms 64 bytes from 192.168.1.156: icmp_seq=6 ttl=64 time=1.58 ms 64 bytes from 192.168.1.156: icmp_seq=7 ttl=64 time=1.79 ms ^C --- 192.168.1.156 ping statistics --- 7 packets transmitted, 7 received, 0% packet loss, time 6010ms rtt min/avg/max/mdev = 1.428/2.313/5.516/1.347 ms [root@think420 rod]# mount -a mount: wrong fs type, bad option, bad superblock on //transporter/Transporter, missing codepage or helper program, or other error (for several filesystems (e.g. nfs, cifs) you might need a /sbin/mount.<type> helper program) In some cases useful info is found in syslog - try dmesg | tail or so. mount: none is already mounted or /proc busy [root@think420 rod]# dmesg | tail [ 81.314329] Bluetooth: RFCOMM socket layer initialized [ 81.314334] Bluetooth: RFCOMM ver 1.11 [ 1925.935475] Unable to determine destination address. [ 1925.935629] Unable to determine destination address. [ 4003.542702] Unable to determine destination address. [ 4238.235033] Unable to determine destination address. [ 4330.112296] Unable to determine destination address. [ 4378.655016] Unable to determine destination address. [ 4737.812258] Unable to determine destination address. [ 4768.906988] Unable to determine destination address. [root@think420 rod]# I ran the mount command a second time, dmesg has added a further entry regarding the destination address. The procedure. as far as I can determine is exactly the same as used in the past, before the "credentials" procedure was introduced. I did try copying over the "credentials" procedure, with one of the other devices, but that did not work either. Cheers, Rod Goslin
I remember a thread in discuss list, some one suggest install cifs-utils
CC: (none) => j.alberto.vc
Ahhh!. I've installed cifs-utils, and it works. No problems at all. This was for the only server seen (Transporter). I'll try the other two, in the same vein. Thanks very much, for the tip. I was beginning to despair. This was with the no "Credentials" method, and leaving out the password (for the moment) Has the "Credentials" method been abandoned?
(In reply to Rod Goslin from comment #3) > Ahhh!. I've installed cifs-utils, and it works. No problems at all. This was > for the only server seen (Transporter). I'll try the other two, in the same > vein. Thanks very much, for the tip. I was beginning to despair. This was > with the no "Credentials" method, and leaving out the password (for the > moment) Has the "Credentials" method been abandoned? Don't think so, try again now you have cifs-utils, if don't works put the terminal messages and look in the logs
I have to admit, that the further I come on this subject, the more puzzled I become. Having successfully mounted the Transporter. I modified the fstab file to cater for the two other drives. They too were successfuly mounted, as root using the command 'mount -av'. All seemed well, until I came to re-boot the machine, when the mounted drives had disappeared. Running 'mount' indicated that the drives were not mounted at boot. Running the command mount -av, as root, once more, and all was well, again. I then re-booted the machine again,and watched the boot process run through as the boot progressed. At the point where the shared drives should have mounted, there were messages to indicate that the mount had failed, on all three drives. Again, doing the mount manually, after logging in, worked. I've looked at dmesg again and note entries :- CIFS VSF: Error connecting to socket. Aborting operation. CIFS VFS: cifs_mount failed w/return code = -101 I'm not currently on the machine in question, so cannot, at the moment, cut and paste the appropriate text. While it's no hassle to run the command 'mount -a, after re-boot, I'd prefer that it worked properly, on boot.
error: -101 is because it tries do do the mount before the network is fully up, hence the failure...
CC: (none) => tmb
add _netdev and nofail to remote options in fstab https://wiki.mageia.org/en/Mageia_2_Errata#Boot_fails_when_webdav.2C_sshfs_etc._entries_exist_in_fstab
Adding _netdev, with or without nofail did not work. I'm getting the same fail messages as before. I added _netdev, comma separated, after the entry for username and password, as I gather is required. I'm wondering if leaving off the password, and simply typing it in on boot would work, but that's more complicated than manually mounting the three drives, post boot
Please paste your fstab, remove sensitive information like passwords before pasting
fstab:- [rod@think420 ~]$ more /etc/fstab # Entry for /dev/sda5 : UUID=90d47b4a-a076-4ff6-925c-8acd3928663d / ext4 noatime,acl 1 1 # Entry for /dev/sda7 : UUID=7d2770d0-2a1d-46ea-80a2-d7a133525527 /home ext4 noatime,acl 1 2 # Entry for /dev/sda3 : UUID=C41629D81629CC6C /media/windows ntfs-3g defaults,nofail,umask=000 0 0 //transporter/Transporter /mnt/Transporter cifs username=xxxx,password=xxxx,_netdev 0 0 //drobo-fs/Public /mnt/Public cifs username=xxxx,password=xxxxx,_netdev 0 0 //drobo5N/Public /mnt/Public2 cifs username=xxxxx,password=xxxxx,_netdev 0 0 none /proc proc defaults 0 0 # Entry for /dev/sda6 : UUID=47f0f175-dfa5-46e6-8e0b-ef5bc45cb24c swap swap defaults 0 0 [rod@think420 ~]$ dmesg appropriate section from re-boot this setting:- 27.292097] CIFS VFS: Error connecting to socket. Aborting operation. [ 27.292172] CIFS VFS: cifs_mount failed w/return code = -101 [ 27.662016] CIFS VFS: Error connecting to socket. Aborting operation. [ 27.662085] CIFS VFS: cifs_mount failed w/return code = -101 [ 27.671158] CIFS VFS: Error connecting to socket. Aborting operation. [ 27.671233] CIFS VFS: cifs_mount failed w/return code = -101
try replacing _netdev with x-systemd.automount (I find this here https://wiki.archlinux.org/index.php/Samba#Automatic_mounting) If i understand this will mount under demand (by example when you try to open /mnt/Public)
Thus, should be at some point cifs-utils a require in a rpm or be installed by diskdrake (Access SMB shares)?
CC: (none) => yves.brungard_mageia
All seems to be running well, for now, and I've just finished installing Mga6 on another machine, which is also ok. At least it is after the usual problems with name resolution, which may stem from my preference to manually setting device IP addresses. The only device which is not manually set is the Transporter which has no function for setting IP addresses, and is set by using the router function of address reservation. I say this, since the Transporter is the only device that the search for servers function will find. Thanks katnatek, for your archlinux link. It inadvertantly gave me some very valuable info, which has solved a VERY long running problem with sharing SMB drives. This is the uid=, and the gid=, options. For years my shares have only been read only. Populating the shared drivers has only been possible with a file manager opened as root. Not a good practice. However by adding these to the options section of the fstab file, the shares are now read/write, which has opened up an enormous opportunity for a wider use of the shared drives. So, now I can throw my backup files onto the Drobo units and even my backups are protected!
(In reply to Rod Goslin from comment #13) I'M Happy that works for you and you found a solution for other issue as side effect.
(In reply to papoteur from comment #12) > Thus, should be at some point cifs-utils a require in a rpm or be installed > by diskdrake (Access SMB shares)? I think the second option is better to keep ISOs as light as can be. Also the tool must set the option x-systemd.automount and set or suggest to set uid and gid see comment #13
This message is a reminder that Mageia 6 is end of life. Mageia stopped maintaining and issuing updates for Mageia 6. At that time this bug will be closed as OLD (EOL). Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 6's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we cannot be able to fix it before Mageia 6 was end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete. -- Mageia Bugsquad
CC: (none) => ouaurelienStatus: NEW => RESOLVEDResolution: (none) => OLD
Thank you for your efforts to resolve this problem, in Mga rev 6. However the problem, if anything, is even worse in Mga 7. I submitted a ticket, some time ago on this subject, and others, on ticket 25521 dated 03/10/2019. However, apart some clarifying some of the parameters, there has been no action on this bug report, either. At your suggestion I have changed "version" to version 7
Version: 6 => 7
Reopening per Comment 17 and https://forums.mageia.org/en/viewtopic.php?t=14685
Resolution: OLD => (none)See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=25521Version: 7 => 8Status: RESOLVED => REOPENEDCC: (none) => fri