6

I'm running two Ubuntu systems, (12.04 on 64-bit AMD desktop system and 14.04 on a 64-bit Intel laptop), and have configured two CIFS drives to be mounted at system start-up following the instructions at

https://help.ubuntu.com/community/MountWindowsSharesPermanently

I've configured these drives using the following entries in /etc/fstab:

//gbsfp1/kgallant /home/kgallant/nethome cifs credentials=/etc/samba/credentials,rw,iocharset=utf8,_netdev,uid=1000,gid=1000 0 0
//gbsfp1/share /home/kgallant/netshare cifs credentials=/etc/samba/credentials,rw,iocharset=utf8,_netdev,uid=1000,gid=1000 0 0

Both drives are always successfully mounted by the time I log in on either machine yet a series of error messages are always reported during system boot that say:

Jul  4 10:52:07 gbsdt1 kernel: [   20.976113] CIFS VFS: Error connecting to socket. Aborting operation
Jul  4 10:52:07 gbsdt1 kernel: [   20.976509] CIFS VFS: cifs_mount failed w/return code = -101

These messages are repeated five to ten times in syslog and, in the case of the 14.04 machine, on the screen during system boot. It appears that both systems are attempting to mount the drives before network services are initialized which I believe is the root cause of the problem. Documentation suggests that the _netdev option would prevent this, but it doesn't seem to have any effect on either the 12.04 or 14.04 systems.

The network drives are provided by a Samba server running on a Fedora 14 machine.

Is there any way to delay mounting these file systems until after network services are available, (if, as I suspect, that is the cause of the problem)? Or any other suggestions would be appreciated.

Thanks in advance!


Output of ls /etc/rc*.d/

/etc/rc0.d:

K01nxserver
K09apache2
K10unattended-upgrades
K20osspd
K20speech-dispatcher
K20xrdp
K21postgresql
README
S20sendsigs
S30urandom
S31umountnfs.sh
S35networking
S40umountfs
S60umountroot
S90halt

/etc/rc1.d:
K01nxserver
K09apache2
K20acpi-support
K20kerneloops
K20osspd
K20saned
K20speech-dispatcher
K20xrdp
K21postgresql
README
S30killprocs
S70dns-clean
S70pppd-dns
S90single

/etc/rc2.d:
README
S19postgresql
S20kerneloops
S20osspd
S20speech-dispatcher
S20xrdp
S50rsync
S50saned
S70dns-clean
S70pppd-dns
S75sudo
S91apache2
S99acpi-support
S99grub-common
S99nxserver
S99ondemand
S99rc.local

/etc/rc3.d:
README
S19postgresql
S20kerneloops
S20osspd
S20speech-dispatcher
S20xrdp
S50rsync
S50saned
S70dns-clean
S70pppd-dns
S75sudo
S91apache2
S99acpi-support
S99grub-common
S99nxserver
S99ondemand
S99rc.local

/etc/rc4.d:
README
S19postgresql
S20kerneloops
S20osspd
S20speech-dispatcher
S20xrdp
S50rsync
S50saned
S70dns-clean
S70pppd-dns
S75sudo
S91apache2
S99acpi-support
S99grub-common
S99nxserver
S99ondemand
S99rc.local

/etc/rc5.d:
README
S19postgresql
S20kerneloops
S20osspd
S20speech-dispatcher
S20xrdp
S50rsync
S50saned
S70dns-clean
S70pppd-dns
S75sudo
S91apache2
S99acpi-support
S99grub-common
S99nxserver
S99ondemand
S99rc.local

/etc/rc6.d:
K01nxserver
K09apache2
K10unattended-upgrades
K20osspd
K20speech-dispatcher
K20xrdp
K21postgresql
README
S20sendsigs
S30urandom
S31umountnfs.sh
S35networking
S40umountfs
S60umountroot
S90reboot

/etc/rcS.d:
README
S25brltty
S37apparmor
S55urandom
S70x11-common
  • Can you post the output of: ls /etc/rc*.d/ – Fabby Nov 23 '14 at 13:40
  • Thanks for looking at this for me @Fabby. Output posted above. – kgallant Nov 24 '14 at 16:59
  • No worries: When I post an answer, just upvote it! That's the best thank you you can give... – Fabby Nov 25 '14 at 10:39
1

On the solution:

In fstab, it'll never work to your satisfaction as you want:

  1. No errors in dmesg
  2. The shares to be mounted before log-in.

I see two solutions:

  1. Use Autofs instead of fstab as Autofs allows you to automatically mount directories on an as-needed basis thus allowing you to manage changes more easily afterwards then the next solution.
  2. Create a custom upstart script and put it in init.d/rc6.d This is the real solution, used for servers that mount nfs volumes, but it'll require you to get your hands dirty, understanding the Linux init process ("boot process" in non-*nix speak)

Let me know which path you want to take, or just accept this as an answer if the above is already enough to point you in the right direction.

|improve this answer|||||
  • This does not provide an answer to the question. To critique or request clarification from an author, leave a comment below their post. – s3lph Nov 23 '14 at 13:38
  • My bad... Correcting now. – Fabby Nov 23 '14 at 13:39
  • Thanks @Fabby. I've installed and configured autofs and it works well. I agree that the init process is the 'proper' way of doing this and hope to explore this further one day when I have the time. Until then, autofs is more than adequate. – kgallant Nov 30 '14 at 17:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.