smb mounts disappear 11.2

Hi, I’ve never had this problem before and its now driving me nuts.

Basically I mount a smb share in suse 11.2 like so

mount //ip/share /mnt/point

That’s fine. It works. A few days later I find all shares I’ve mounted like that have mysteriously disappeared. I can’t find out why, nothing in logs, no obvious causes.

When I say disappear I mean its like something did an umount /mnt/point. They no longer appear in the mount list, they are no longer mounted, and I need to type in the mount command for them to come back.

I tend to leave the boxes running until they crash or need a reboot, and always have. This problem I’ve only seen in 11.2. I have a 11.1 and 11.0 boxes running too, and the mounts are stable on those.

I can’t find any references anywhere to this behaviour. Any help/ideas, would be appreciated.

Just a thought, have you checked your cron jobs to see if something there might cause the problem?

Just checked. Nope nothing in there, other than smolt and register suse. I can’t even pinpoint when this happens, its not every day, but after an unknown time its disappeared. At first I thought I must have rebooted or forgot to connect, but then I realised its simply disappearing after some time.

I recommend you use the cifs driver; i.e. “mount -t cifs //ip/etc” rather than just “mount //ip/etc”.

And also have a think about making the mounts permanent with a mount specification placed in fstab. For both ad-hoc mounts and permanent mounts see the syntax options in this tutorial:
Samba: HowTo Mount a CIFS Network Share [AKA Map Network Drive] in openSUSE 11 plus FAQs

Okay can try the mount -t cifs thing. On the fstab, I do have a permanent one in there, but in the past the command line worked fine for the temporary ones. 11.2 - the fstab one stays fine, just the mount one doesn’t. Will try one of them with -t cifs

I am having exactly the same problem - opensuse 11.0, 11.1. There are no cron jobs and I can make the problem disappear by using kmail with a mail directory on the samba share. kmail has to be logging in to the mail server, in which case the activity keeps the share alive. It is not enough just to have kmail running without actively logging in to the mail server.

I am mounting with mount.cifs

/sbin/mount.cifs //<server>/$USER $HOME/.import -o noperm -o setuids -o guest

The mounted share disappears in about 10 to 20 minutes.

I’m very unclear on this but:
Can you run the options separately? Should they be more like this:

/sbin/mount.cifs //<server>/$USER $HOME/.import -o noperm,setuids,guest

It works either way, with the same result.

Well, for whatever reason, I am getting the distinct impression that there is some busybody daemon at work here, tidying up 'and dropping ‘unused’ mounts - perhaps for a mobile connectivity scenario.

They is nothing flaky about it. The connections are there and they work. And then they disappear. Any ideas anyone?

Idea #1: I assume this is all done as root, so I won’t ask about that :wink:

Idea #2: the owner on the server is the same as the user on the client, so $USER from the client is recognised properly on the server?

Idea #3: I’d guess that if a low impact error situation exists, maybe the busybody daemon disconnects the mount after e.g. 100000 repetitive error situations are generated. Maybe try a more conventional mount like this:

sudo mount -t cifs -o guest,uid=michael,gid=users // /home/michael/.import

Idea #4: if you open a browser (e.g. Dolphin) and run this address in the address bar: smb://servername/michael – are you asked for any credentials? For the “-o guest” to work, the answer must be “no”.

OK, now I’m out of ideas lol!

#1 mount.cifs has been setuid’d

#2 yes, $USER matches - but I am not so sure about the uid numbers. The share in question resides on a Linksys NAS200 and this info is probably not easily accessible. But it is similar results on an 11.0 and an 11.1 client to an 11.0 server. And here the uid’s and id’s do both match

#3 will try the alternative mount command line. I doubt this is errors as putting kmail on the case allows the connection to stay - I don’t see that as a strong case for suppressing errors - although I can see it could give an event to reset an error count.

#4 Dolphin requires no credentials

Thanks for your input - it is making the deamon lookmore likely to me.

OK, started from the top, got the share mounted, got this from mount:

$USER@<clientr>:~> mount
/dev/mapper/system-root on / type ext3 (rw,acl,user_xattr)
/proc on /proc type proc (rw)                             
sysfs on /sys type sysfs (rw)
debugfs on /sys/kernel/debug type debugfs (rw)
udev on /dev type tmpfs (rw)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
/dev/sda1 on /boot type ext3 (rw,acl,user_xattr)
/dev/mapper/system-spare on /home type ext3 (rw)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
securityfs on /sys/kernel/security type securityfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
//<server>/$USER on /$HOME/.import type cifs (rw,mand,nosuid,nodev,user=$USER)

waited for connection to drop and got this:

$USER@<clientr>:~> mount
/dev/mapper/system-root on / type ext3 (rw,acl,user_xattr)
/proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
debugfs on /sys/kernel/debug type debugfs (rw)
udev on /dev type tmpfs (rw)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
/dev/sda1 on /boot type ext3 (rw,acl,user_xattr)
/dev/mapper/system-spare on /home type ext3 (rw)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
securityfs on /sys/kernel/security type securityfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
gvfs-fuse-daemon on /$HOME/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=$USER)

Does anyone have any idea why the gvfs fuse daemon mounts itself and what it does? And whether it is even relevant? Any input welcome!

Another snippet. Tried that and it behaves identically, dropping out in a few minutes.

Perhaps not! Uninstalled gvfs stuff - still the same problem.

I thought you might have found it there. I’m sure it’s some extra software installed which is being helpful. I never had the problem in 11.0 11.1, just 11.2 but I was more generous is selections in 11.2

No, no joy with this today. Poked away at a few things. I have the problem in 11.0 and 11.1, so I would go along with it being ‘something extra’. Interestingly, it is enough to have kMail working away with the mail on a shared drive - I only discovered the problem when I needed to put something onto the shared drive in a situation where kMail was not running. It is not enough to have a text file open in kWrite…

Just checked. 5.5 hours up time and the mount is good with kMail. But it is no more than 10 or 15 minutes otherwise

OK, a little closer.

from /var/log/samba/log.smbd

[2010/01/19 22:03:36,  1] smbd/server.c:open_sockets_smbd(644)
  Reloading services after SIGHUP

I have been watching this for a little while, and this entry comes up every 15 minutes - and it seemed to coincide with loss of my samba mount. So I sat running mount and watching the clock. Behold, I lost my mount at 22:03:37.


Same entries in smbd.log on my machine which is still holding its mount with kmail running, but no drops.

Interesting or what? Comments? Where to go next with this?

A thread from Another Place which looks relevant.

Reloading /etc/samba/smb.conf smbd only

OK. It happens when the DHCP lease is up. So one workaround is to use static addressing.

Another workaround is to increase the DHCP lease time. I have proved this one for myself.

As I see it, about half way through the DHCP lease, openSuse renews the lease and sends SIGHUP [SIGnal Hang Up] to relevant processes - in this case smbd. smbd restarts and drops any mounts which it decides are not in use.

Whether this behaviour is ‘correct’ or ideal is probably worth a debate somewhere.

I did think the same as you, but then when I manually tried it didn’t drop the connections. But thanks for confirming it is that. Personally it seems a bit strange to do that…