Does this problem sound familiar to anybody. On a busy Linux server that exports lots of Samba Shares for video editing, upgrading from Samba 3.0.23d to Samba 3.0.28a has caused a huge problem. After several hours of use, ALL exported Samba Shares suddenly appear to have NO FILES to ALL CONNECTED OS X CLIENTS. Also, it is still possible to log into shares (so to some extent, Samba is still working). But when you log in, the shares look empty as well. There are NO ERROR MESSAGES in the standard "level 3" samba logs. There are no error messages in the syslog. smbd seems to be running fine. Restarting Samba, and reconnecting to the shares brings the files back. The problem I am describing has been very reproducible. It's just a matter of waiting a few hours and occurs. Reverting back to Samba 3.0.23d makes the problem go away. Any ideas? Andy Liebman
Jeremy Allison
2008-Jun-20 18:22 UTC
[Samba] Samba Shares Suddenly Look Empty with 3.0.28a
On Fri, Jun 20, 2008 at 10:47:08AM -0400, Andy Liebman wrote:> Does this problem sound familiar to anybody. On a busy Linux server > that exports lots of Samba Shares for video editing, upgrading from > Samba 3.0.23d to Samba 3.0.28a has caused a huge problem. > > After several hours of use, ALL exported Samba Shares suddenly appear to > have NO FILES to ALL CONNECTED OS X CLIENTS. Also, it is still possible > to log into shares (so to some extent, Samba is still working). But when > you log in, the shares look empty as well. > > There are NO ERROR MESSAGES in the standard "level 3" samba logs. There > are no error messages in the syslog. smbd seems to be running fine. > Restarting Samba, and reconnecting to the shares brings the files back. > > The problem I am describing has been very reproducible. It's just a > matter of waiting a few hours and occurs. Reverting back to Samba > 3.0.23d makes the problem go away. > > Any ideas?Can you get traffic captures from when the OSX clients are failing to see the files. Sounds like something George and James would be interested in looking at. Jeremy.