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.
Thanks
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.
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.
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
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 //192.168.33.30/michael /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”.
#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!
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
[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.
Coincidence?
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?
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…
