Bug 7673 - In /etc/fstab the line with cifs does not work
Summary: In /etc/fstab the line with cifs does not work
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: i586 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Colin Guthrie
QA Contact:
URL:
Whiteboard:
Keywords:
: 8745 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-10-02 11:34 CEST by Jacques Pronchery
Modified: 2015-06-02 20:32 CEST (History)
3 users (show)

See Also:
Source RPM:
CVE:
Status comment:


Attachments
Output from journalctl -ab | grep -i mount (2.25 KB, text/plain)
2014-02-04 22:14 CET, Richard Walker
Details

Description Jacques Pronchery 2012-10-02 11:34:48 CEST
At boot in /etc/fstab the line :
//usbstation/usbshare /mnt/usbshare cifs username=% 0 0
does not work.
But in root the command :
mount.cifs //usbstation/usbshare /mnt/usbshare
work fine.
I remark in the file /proc/filesystems there is not "cifs".
Comment 1 Jacques Pronchery 2012-10-02 20:29:46 CEST
I think the boot try to mount my external disk before the network is up.
If I write in /etc/rc.d/rc.local :
mount.cifs //usbstation/usbshare /mnt/usbshare -o user=%
it work fine.
Comment 2 Jacques Pronchery 2013-01-15 16:50:13 CET
Now mount.cifs does not work.
Comment 3 Sébastien GUERIN 2013-01-18 23:07:14 CET
You must use _netdev option in fstab to ensure that mount is waiting for network is enabled

CC: (none) => sebastien.guerin.news

Comment 4 Jacques Pronchery 2013-03-08 10:00:45 CET
If I try to mount an external disk in a console I have :

[root@localhost jacques]# mount.cifs //livebox/DisquesUSB /mnt/Livebox -o guest
mount error(38): Function not implemented
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
[root@localhost jacques]# 

Mount.cifs does not work.
Comment 5 Richard Walker 2014-02-04 21:28:16 CET
I have just encountered the same problem in MGA. I started a thread in the Forum (CIFS share in fstab does not automount (MGA3)) after reading a similar thread dating back to last October (2013).

Most of the suggested solutions I have found indicate the need for the _netdev option in the fstab entry but this does not appear to be a complete solution. Or any kind of a solution.

My fstab entries are:
//BTHUB5/USB2 /home/EKshare cifs [_netdev,]sec=none 0 0
//BTHUB3/USB_Disk /home/EKshare2 cifs [_netdev,]sec=none 0 0

...where [_netdev,] may be either present or absent. It makes no difference.

After booting, a simple mount -a works, suggesting that the basic structure of the fstab entries is correct.

I have tried hacking my way through the arcana of systemd and got lost. Logic suggests it should be the culprit, but it knows how to keep its secrets (from me). Who said security by obscurity doesn't work?:-)

Richard

CC: (none) => richard.j.walker

Comment 6 Florian Hubold 2014-02-04 21:52:54 CET
(In reply to Richard Walker from comment #5)
> My fstab entries are:
> //BTHUB5/USB2 /home/EKshare cifs [_netdev,]sec=none 0 0
> //BTHUB3/USB_Disk /home/EKshare2 cifs [_netdev,]sec=none 0 0
> 
> ...where [_netdev,] may be either present or absent. It makes no difference.

Just to be 100% sure, there are no square brackets in your fstab entries when _netdev is present?

What does "journalctl -ab | grep -i mount" say?

CC: (none) => doktor5000

Comment 7 Richard Walker 2014-02-04 22:14:40 CET
Created attachment 4930 [details]
Output from journalctl -ab | grep -i mount
Comment 8 Richard Walker 2014-02-04 22:16:26 CET
That is [correct|incorrect] :~)

Sorry, you made me grin. Yes we have no square brackets.

See attached for the other
Comment 9 Florian Hubold 2014-02-04 23:55:18 CET
The latter issue by Richard has been resolved via

systemctl enable remote-fs.target && systemctl start remote-fs.target

And previously reported in forums, and confirmed by Colin that this should be enabled: https://forums.mageia.org/en/viewtopic.php?p=40883#p40883

Now the big question is, why isn't remote-fs.target enabled by default?

CC'ing Colin.

Assignee: bugsquad => mageia

Comment 10 Colin Guthrie 2014-02-05 10:19:37 CET
It's enabled in the package %post scripts.

Fresh install here has it enabled.
Comment 11 Richard Walker 2014-02-05 11:14:08 CET
I have to be brief as I am about to start a long day of travelling, but I repeated the steps indicated by Florian in yesterday's Forum thread on this topic to get another m/c on this network to mount the same shares on boot.

The box is MGA3 (rebuilt MGA2) with a fresh install last December (22nd). It also fails to mount but at least the remote-fs.service was enabled. However, it fails to mount the CIFS shares as it finds the network not ready. This is not the same problem which I encountered and reported in comment 5.

The entries in my /etc/systemd/system/multi-user.target.wants directory have many different dates:

Year 2013
Feb 10   avahi-daemon, crond, acpid, irqbalance, cpupower, ntpd
Feb 22   atd
Feb 23   smartd
May 28   mysqld
Jun 03   lm_sensors, sensord
Oct 23   rpcbind
Nov 30   sshd
Dec 03   gpm
Dec 04   irda, rsyslog
Year 2014
Jan 26   saslauthd
Feb 04   remote-fs

The machine built in December has the contents of the same directory all dated 22 December.

Must dash. Back tomorrow.

Richard
Comment 12 Florian Hubold 2014-02-07 21:34:54 CET
*** Bug 8745 has been marked as a duplicate of this bug. ***
Florian Hubold 2014-02-07 21:56:38 CET

See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=4042

Comment 13 Richard Walker 2014-02-08 01:02:34 CET
To continue from Comment 11, I have spent a few days away from home and had an opportunity to take a closer look at a m/c I built last October. Did not get the opportunity to check how it mounts, or doesn't mount network shares at boot but the "creation" date for the various /etc/systemd/system/multiuser.....etc links tells another slightly strange story. 

As Colin has said, the %post script in, presumably, the systemd-units rpm will enable remote filesystems, but that doesn't establish for me how and when systemd-units is installed. 

The October build I have just been visiting appears to have started in the very early morning of October 4 (about 3am) but the remote-fs enabler did not appear until after 9am later the same day. That could be accounted for by the installer sitting waiting for me to do the post-install stuff while I slept.

So, I suppose my question is which installation-time configuration option is responsible for activating the remote-fs target? It must surely be something which I could leave out without understanding the consequence.

R
Comment 14 Florian Hubold 2015-06-02 20:32:05 CEST
Marking fixed as mentioned by comment 10 - this may have been an interim issue from mga2/mga3 transition.

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


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