Bug #911
closed
smbfs mount command fails during system boot
0%
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.
Updated by Gordon Ross over 12 years ago
There were fixes published for this in:
http://cr.opensolaris.org/~gwr/jk-vfstab/
but never integrated.
Updated by Gordon Ross over 12 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 over 12 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 over 12 years ago
So, is the service missing a dependancy?
Updated by Gordon Ross over 12 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 over 12 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 over 12 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.)