Bug 22011

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) => ouaurelien
Status: NEW => RESOLVED
Resolution: (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=25521
Version: 7 => 8
Status: RESOLVED => REOPENED
CC: (none) => fri