cifs share not mounting on boot when using \\host\share syntax in fstab

It would be nice if you didn't change your /etc/fstab line to obfuscate it, especially given that all the information is present in the mountall --debug log and the changes make it harder to match up the log with the fstab line.

  fhs mounted
  [...]
  mounted: local 3/3 remote 0/0 virtual 12/12 swap 1/1

These lines towards the end of the log show that mountall has found all the filesystems needed in order to boot, so it's not because of a deadlock waiting for the network; that previous bug with mountall appears to be fixed.

However, there's no indication in this mountall log of the network interface coming up and signalling mountall to mount the network filesystems. Is mountall still running after the end of this logfile, or has it terminated without finishing?

The cifs mount has been tagged as "other", and is waiting for the device "\192.168.170.8\music"

It should be tagged as a network device (I copied the list from mountnfs.sh, so I guess that never dealt with cifs either).

I'm not sure whether that tagging will result in the device dep going away or not, it shouldn't be there.

(there may be a bug where network devices outside the fhs aren't getting dealt with properly too)

Actually, cifs is in the list.

I think the bug is simply that it's waiting on that fictional device path

Oh, no, ignore me.

That's the "this is what I'm waiting for" message, no dep is there

This is simply waiting for the USR1 signal to indicate a network device is already up

What kind of information do you still need? the mountall --debug did never finished. It keeps on waiting & waiting for something to happend.

How is your network interface started? If the network is brought up by any of the standard scripts, then /etc/network/if-up.d/upstart should trigger signalling mountall to retry the network mounts.

If instead of mounting the filesystems by hand, you run 'sudo killall -USR1 mountall', does mountall resume and mount the network filesystems for you?

wireless network is started by gnome. the standard way

i will check this comment as soon i get home:
>If instead of mounting the filesystems by hand, you run 'sudo killall -USR1 mountall', does mountall resume and mount the network >filesystems for you?

Did this stop you logging into GNOME?

Your log shows the virtual finished, local finished and fhs mounted events which should result in gdm starting - letting you log into GNOME. As soon as your network comes up by NM, the cifs mount should mount.

after this nothing happend:
>sudo killall -USR1 mountall

>Did this stop you logging into GNOME?
No, i can log into gnome but no share is mounted

>Your log shows the virtual finished, local finished and fhs mounted events which should result in gdm starting - letting you log into >GNOME. As soon as your network comes up by NM, the cifs mount should mount.

This always happend before, not anymore

Can you show a mountall log that includes any output in response to 'sudo killall -USR1 mountall'?

after 'sudo killall -USR1 mountall' see attachment mountall2.txt

now after 'sudo mount -a' see the mountall3.txt

Having the same exact problem. Same fstab line as in Jaunty, but not working.
Tried both wired and wireless connection.

"sudo mountall --debug" keeps waiting forever, although network is up.

"sudo mount -a" mounts my cifs share flawlessly.

I've been able to reproduce this here by adjusting one of my mountpoints; for some reason I get additional information in my logs that didn't show up in yours, which provides the key:

usr1_handler: Received SIGUSR1 (network device up)
queue_fsck: /srv: no check required
mounting /srv
spawn: mount -a -t cifs -o credentials=/etc/samba/becquer.creds,rw,file_mode=0644 \becquer\media /srv
spawn: mount /srv [25768]
mount error: improperly formatted UNC name. \becquer\media does not begin with \\ or //
No ip address specified and hostname not found
mountall: mount /srv [25768] terminated with status 1
mountall: Filesystem could not be mounted: /srv

This is when using the \\host\share syntax in /etc/fstab.

As a workaround, you can switch your /etc/fstab entry from \\host\share to //host/share - the latter is the preferred syntax anyway, due to shell escaping issues with using \ on Unix.

Marking this triaged, this reproducible test case should be enough to isolate the bug.

Hi Steve,

//host/share did the trick. Is this still a bug or should be reported the way it should be from now on?

Im asking this since on forums there are lot of threads about doing it like this \\host\share

Thanks for helping resolving this issue. I personally think is better to do it the unix way //host/share anyway

On Sun, Oct 18, 2009 at 07:37:38PM -0000, Zer0 wrote:
> //host/share did the trick. Is this still a bug or should be reported
> the way it should be from now on?

It's still a bug; mountall shouldn't mangle any fstab lines that worked with
pre-mountall scripts.

> Im asking this since on forums there are lot of threads about doing it
> like this \\host\share

> Thanks for helping resolving this issue. I personally think is better to
> do it the unix way //host/share anyway

Yes, it definitely is better; using the non-unix syntax is always going to
be a ready source of new bugs in its handling. We should be committed to
fixing those bugs when we find them, but users should spare themselves the
trouble of dealing with those bugs in the first place by using //host/share.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

On Sun, 2009-10-18 at 21:04 +0000, Steve Langasek wrote:

> On Sun, Oct 18, 2009 at 07:37:38PM -0000, Zer0 wrote:
> > //host/share did the trick. Is this still a bug or should be reported
> > the way it should be from now on?
>
> It's still a bug; mountall shouldn't mangle any fstab lines that worked with
> pre-mountall scripts.
>
mountall doesn't mangle fstab at all, in fact it doesn't parse it! The
fstab parsing is entirely inside glibc, and is the same code that mount
uses [getmntent()].

Is it possible that glibc has changed? (It wouldn't be the only
backwards incompatible change introduced this cycle </bitter>)

The getmntent() manpage says that a \134 must be used to represent a
backslash, so \\host\share should be \134\134host\134share ?

Scott
--
Scott James Remnant
<email address hidden>

> Is it possible that glibc has changed?

No, what's changed is that getmntent() was *not* ever used to parse /etc/fstab previously at boot time. This is not what 'mount' uses internally, so it was not part of the codepath when running 'mount -a'. It's fine that glibc has an opinion on what the format of /etc/fstab should be, but that's not a standard, and it's not what util-linux implements.

Hi again,

the \ issue is not the only problem. After boot & everything is mounted after changing to // and you log out & log in, the mounts are not mounted anymore.
Since to be there are more regretions than only the slash issue.

On Wed, Oct 21, 2009 at 08:43:25PM -0000, Zer0 wrote:
> the \ issue is not the only problem. After boot & everything is mounted after changing to // and you log out & log in, the mounts are not mounted anymore.
> Since to be there are more regretions than only the slash issue.

mountall doesn't unmount any filesystems. You should find out what's
unmounting these shares, and file a bug there.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Obviously, we should have our tools and libraries agree on the format of important files ;-)

I just noticed the following text in fstab(5):

       The proper way to read records from fstab is to use the routines getmn‐
       tent(3).

mountall is using the documented "proper way" to read this file (the man page even comes with util-linux!) If the proper way isn't compatible with mount, we should definitely fix this in eglibc

(should be trivial to copy any code from mount - it looks like the code was copied from glibc in the first place!)