Bug 2043 - smbd does not cwd out on disconnect
Summary: smbd does not cwd out on disconnect
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: File Services (show other bugs)
Version: 3.0.3
Hardware: x86 Linux
: P3 normal
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
Depends on:
Reported: 2004-11-17 00:28 UTC by David Leonard (550 5.7.1 Unable to deliver)
Modified: 2005-08-24 10:17 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description David Leonard (550 5.7.1 Unable to deliver) 2004-11-17 00:28:47 UTC
I'm sharing an automounted cdrom mount, and smbd keeps the mount point busy by
having its working directory in the last accessed directory.

Even though the windows client disconnects, lsof tells me that the smbd process
is the reason why umounts are failing, and why I can't eject the cdrom.

My workaround is to do something like access another share on the samba server.
This causes smbd to cwd elsewhere, releasing the mounted filesystem and then
eject works.
Comment 1 David Leonard (550 5.7.1 Unable to deliver) 2004-11-17 00:33:43 UTC
Actually now I come to look at it, it looks like a child process of smbd had
cwd'd to the share. Maybe the windows client hadn't fully disconnected...

Anyway, here is extra info

On Fedora Core 2's /etc/samba/smb.conf

        comment = DVD/CDR
        path = /var/autofs/ejectable/cdrom
        guest ok = yes

        /var/autofs/ejectable /etc/auto.ejectable --timeout=5

        cdrom -fstype=iso9660,ro,sync,nodev,nosuid :/dev/cdrom

# ls -la /dev/hdc
brw-rw----  1 root disk 22, 0 Feb 24  2004 /dev/hdc
# lsof | grep 22,
smbd      31071    root  cwd    DIR       22,0        308      40960
# cat /var/run/smbd.pid 
Comment 2 Gerald (Jerry) Carter (dead mail address) 2005-02-08 06:20:25 UTC
This has been fixed for several releases now IIRC.  Please reopen if tyhe bug
still exists in 3.0.11
Comment 3 Gerald (Jerry) Carter (dead mail address) 2005-08-24 10:17:29 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.