Bug #911

smbfs mount command fails during system boot

Added by Gordon Ross about 3 years ago. Updated almost 3 years ago.

Status:Resolved Start date:2011-04-17
Priority:Low Due date:
Assignee:Gordon Ross % Done:

0%

Category:- Spent time: -
Target version:-
Difficulty:Medium Tags:needs-triage

Description

This was originally:
http://bugs.opensolaris.org/view_bug.do?bug_id=6799647

When smbfs mounts are made from /etc/vfstab these
mounts cause the "fs-local" service to fail startup:

mount_smbfs: service "svc:/network/smb/client:default" not enabled.
svc:/system/filesystem/local:default: WARNING: /sbin/mountall -l failed: exit status 3
Mounting ZFS filesystems: (9/9)
Apr 17 22:17:17 svc.startd[10]: svc:/system/filesystem/local:default: Method "/lib/svc/method/fs-local" failed with exit status 95.
Apr 17 22:17:17 svc.startd[10]: system/filesystem/local:default failed fatally: transitioned to maintenance (see 'svcs -xv' for details)

This issue is for the mount_smbfs (at boot) problems.
See issue 910 for the mountall parts.

History

Updated by Gordon Ross about 3 years ago

There were fixes published for this in:
http://cr.opensolaris.org/~gwr/jk-vfstab/
but never integrated.

Updated by Gordon Ross about 3 years ago

With the related issue 910 fixed (mountall/umountall)
http://www.illumos.org/issues/910
it is possible to have both nfs and smbfs mounts in /etc/vfstab, i.e.

myserver:/test - /t  nfs - yes bg
//myserver/test - /x smbfs - yes noacl,noprompt,fileperms=644

You typically need auth info in /root/.nsmbrc for this, i.e.:
[myserver]
domain=myserver
user=test
password=test

Updated by Gordon Ross almost 3 years ago

Actually, some of the fixes referred to in note 1 were integrated.
Just not the part to deal with the possibility that mount_smbfs
might be called when svc:/network/smb/client is still coming up
(state="offline").

The reason this happens is that the start method script for smbfs
(just like nfs) calls: mountall -F smbfs, but that mountall needs
this same service to be online. In our case, the mountall runs in
the background, so all it needs to do is wait a little for the service
to go online. That happens right after the method script finishes.
The nfs equivalent to this is the "bg" (background) mount option.

Updated by Gary Mills almost 3 years ago

So, is the service missing a dependancy?

Updated by Gordon Ross almost 3 years ago

No, it's not a missing dependency problem. Rather, an odd design
(inherited from nfs) where mountall is called just before the end
of the start method for this service. In nfs that works because you
have to specify the "bg" (background) mount option, which lets the
mount keep trying. In smbfs, we did not offer a background mount
option, but do run the mountall asynchronously (via ctrun -l none).
The only remaining thing needed then is for mount_smbfs to wait
(just a little) for its own service to transition "offline" to "online".

Updated by Rich Lowe almost 3 years ago

I'm pretty sure NFS works because it contains no explicit check that its service is online in its own mount path, so it will succeed assuming the meat of nfs/client is running.

I still think that the check of smb/client in the smbfs mount* is crap, or at least something which would be better as a warning. It's the only thing causing this "wait a while and hope" approach to be necessary.

Updated by Gordon Ross almost 3 years ago

Thanks for questioning the reasons for checking the service state.

I looked into this some more, and I see that the service startup
for network/smb/client actually does synchronously wait for the
service to be ready (smbiod-svc.c ; daemonize_init / fini) before
that command exits to the service start method script. I had
forgotten about that mechanism.

Therefore, the mountall that follows does have everything it
needs running to successfully do mount -F smbfs via mountall,
in spite of the service state being "offline" at this point.

Further, the old code in smbfs/mount.c that printed a helpful
message about needing svc:/network/smb/client online is
actually already handled elsewhere now. So...

An improved fix is to just delete this stuff from smbfs/mount.c
(See updated webrev.)

Updated by Gordon Ross almost 3 years ago

  • Status changed from New to Resolved

13348:4389ac5d32c3

Also available in: Atom PDF