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".
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.
Now mount.cifs does not work.
You must use _netdev option in fstab to ensure that mount is waiting for network is enabled
CC: (none) => sebastien.guerin.news
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.
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
(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
Created attachment 4930 [details] Output from journalctl -ab | grep -i mount
That is [correct|incorrect] :~) Sorry, you made me grin. Yes we have no square brackets. See attached for the other
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
It's enabled in the package %post scripts. Fresh install here has it enabled.
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
*** Bug 8745 has been marked as a duplicate of this bug. ***
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=4042
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
Marking fixed as mentioned by comment 10 - this may have been an interim issue from mga2/mga3 transition.
Status: NEW => RESOLVEDResolution: (none) => FIXED