13.10-Network (cifs) drives do not load.

I should also point out that I can mount the drives manually and I can mout the drives with 'sudo mount -a'.

> from mountall-net.log:

> /proc/self/fd/9: 3: kill: No such process
> /proc/self/fd/9: 3: kill: No such process

And what is the output of /var/log/upstart/mountall.log? Please boot with '--verbose' added to the kernel commandline and attach the resulting log file.

So the logs together show that the filesystems are not being mounted because the mount is attempted before the network is up, and that mountall has for some reason exited before the network comes up and the mountall-net job has a chance to signal mountall with SIGUSR1. I'm not sure what's causing this; will try to reproduce it here.

On previous releases, I usually got the cifs error when the drives were mounted, but they were mounted once I logged in and opened Dolphin. So, something between 13.04 and 13.10 changed. I should also note that I upgraded to 13.10. It's not a clean install.

So I've just debugged bug #1233610 regarding a similar issue with NFS mounts. Do you have a hostname for 192.168.1.13 that's resolvable via DNS (*not* via /etc/hosts)? If so, perhaps you could try mounting by name instead of IP to work around the kernel's behavior when asked to mount from an unreachable server.

OK, just so I didn't misunderstand, I made these changes in fstab:

//www.buddlespit.org/Shares /mnt/Shares cifs guest,uid=1000,iocharset=utf8,sec=ntlmv2 0 0
//Server/Homes /mnt/Homes cifs auto,_netdev,credentials=/home/pat/.smbcredentials,iocharset=utf8,sec=ntlmv2 0 0

I own www.buddlespit.org and it's pointed at the server, and the servers host name is 'Server'

I can mount via 'sudo mount -a' both with the above addresses and with 192.168.1.13.

I've attached another mountall.log

In the latest log I do see the network mounts being attempted several times, but with no trigger shown in the log. That seems to be consistent with the mountall-net.log, which shows mountall isn't there to be signalled. What does the network configuration for this machine look like? Are you using /etc/network/interfaces, NetworkManager, or something else to manage your networks, and how many network interfaces does this client have?

Once the system is booted, is mountall still running? ('sudo initctl status mountall') Have you modified any of the mountall upstart jobs in the past? (Please run 'apport-collect -p mountall 1235013' to attach information about the package state to the bug.)

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

Sorry, ran it twice because of an error.

pat@Pats-Main:~$ sudo initctl status mountall
[sudo] password for pat:
mountall start/running, process 266

I believe I'm running the default NetworkManager installed by Kubuntu. I haven't changed it.

/etc/network/interfaces:
# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback

/etc/NetworkManager/NetworkManager.conf:
[main]
plugins=ifupdown,keyfile,ofono
dns=dnsmasq

no-auto-default=8C:89:A5:32:34:31,

[ifupdown]
managed=false

Ok, so no modified conffiles.

> //Server/Homes /mnt/Homes cifs auto,_netdev,credentials=/home/pat/.smbcredentials,iocharset=utf8,sec=ntlmv2 0 0

This is a potential source of boot-time unreliability, fwiw; /mnt/Homes can't be mounted until /home/pat/.smbcredentials is available, but this information is encoded in the mount options in a way mountall can't parse. It might be best to move the key file to the root filesystem.

$ sudo initctl status mountall
mountall start/running, process 266
$

and is process 266 actually running? ('ps 266')

pat@Pats-Main:~$ ifconfig
eth0 Link encap:Ethernet HWaddr 8c:89:a5:32:34:31
          inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0
          inet6 addr: fe80::8e89:a5ff:fe32:3431/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:176193 errors:0 dropped:0 overruns:0 frame:0
          TX packets:228021 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:69686165 (69.6 MB) TX bytes:283259872 (283.2 MB)

lo Link encap:Local Loopback
          inet addr:127.0.0.1 Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING MTU:65536 Metric:1
          RX packets:2216 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2216 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:273262 (273.2 KB) TX bytes:273262 (273.2 KB)

pat@Pats-Main:~$ sudo initctl status mountall
[sudo] password for pat:
mountall start/running, process 266
pat@Pats-Main:~$ ps 266
  PID TTY STAT TIME COMMAND

I moved ~/.smbcredentials to /.smbcredentials and chown'ed it to root:pat 0777.

It's still not automounting on login. Let me know when you're getting way too frustrated for this.

Oh, already well past frustrated, here. :) But the latest results at least confirm one thing, the mountall process is dying before mountall-net signals it (and before it successfully mounts the network mounts, either). This doesn't make it any less confusing - if mountall died, upstart should have detected that and marked the job as 'stopped' (and possibly handled any errors from mountall itself).

Something's going very wrong here, but I have no guesses as to what, except if you have some local upstart jobs that are blocking signals or some of your system binaries have been modified (which you could check by installing debsums and running 'debsums -s', I suppose).

OK, I accuired a wild hair and downgraded mountall to v2.48build1(raring) and now everything is alright. I still get the flood of cifs errors on boot, but once I log on, my cifs shares are mounted. I looked for my mountall.log, but it appears to have gone MIA... :$

Ah, and now I'm able to reproduce this problem here... and have pinned down which change of mine caused it. Apparently mountall-net was broken for everyone, and I just managed to not notice. Sorry about that. I'll push a fix ASAP for 13.10.

This bug was fixed in the package mountall - 2.52

---------------
mountall (2.52) unstable; urgency=low

  * Don't emit extra 'mounting' events for mounts already in progress; this
    will cause double triggering of some jobs for remote filesystems, and
    can also cause us to miss 'mounted' events. LP: #1048017.
  * Fix mountall upstart job to not start a subshell for reading
    /proc/cmdline, since this causes upstart to lose track of the daemon
    process and leaves mountall-net unable to signal it to retry network
    mounts. LP: #1235013.
 -- Steve Langasek <email address hidden> Wed, 09 Oct 2013 04:12:51 +0000