CIFS VFS unexpected SMB signature

При монтировании Windows шары, в терминале сыпятся следующие строки:

314013.689376 CIFS VFS: Unexpected SMB signature
314014.969252 CIFS VFS: Unexpected SMB signature
314014.984662 CIFS VFS: Unexpected SMB signature

На Windwos XP, Server 2003 по умолчанию включено подписывание SMB.

Проблема встретилась только с шарой на Windows Server 2003, на XP такого не замечал.
На сайте microsoft подробно об этом написано http://support.microsoft.com/kb/887429

Вкратце решение для Windows Server 2000/2003/XP:

MS SQL SERVER Suspect

MS SQL SERVER База данных в режиме Suspect

Общие шаги по восстановлению работоспособности базы:

«Suspect» этот статус присваивается базе в случае аварийного состояния.

Часто такой причиной является неисправность Журнала транзакций (transaction log). Попытка подключить базу без логов ожидается примерно такое сообщение об ошибке: 

Server: Msg 945, Level 14, State 2, Line 1
Database ' db_zup' cannot be opened because some of the files could not be activated.
Server: Msg 1813, Level 16, State 2, Line 1

Could not open new database 'db_zup'. CREATE DATABASE is aborted. Решить эту ситуацию можно созданием новой базы с таким же именем и такими же по именам и расположению .mdf и .ldf файлами.
Чтобы можно было не останавливать сервер целиком, укажите параметр базы autoclose = true. 

Теперь подменяем файл .mdf . Можно также использовать проверку физической целостности базы командой DBCC CHECKDB.
Если останавливали сервер, Стартуем, не обращаем внимания на статус базы
и в Query Analyzer выполняем:

Для MS SQL Server 2000: 

Use master
go --разрешаем изменения в системных базах
sp_configure 'allow updates', 1
reconfigure with override
go –-запоминаем значение
select status from sysdatabases where name = 'имя базы'
go –-изменяем статус нашей базы
update sysdatabases set status= 32768 where name = '<db_name>'
go 

Для MS SQL Server 2005

Use master
go
sp_configure 'allow updates', 1
reconfigure with override
go
alter database имя_базы set EMERGENCY
use master
go
sp_dboption 'имя_базы', 'single_user', 'true'
go

Перезапустить SQL сервер, база должна быть видна в emergency mode 

Создадим новый Журнал транзакций и выполним полное тестирование.

Для Ms SQL 2000

DBCC REBUILD_LOG('имя_базы', '<имя нового лога с указанием полного пути>')
GO
Use master
GO
sp_dboption 'имя_базы', 'single_user', 'true'
GO
USE имя_базы
GO
DBCC CHECKDB('имя_базы', REPAIR_ALLOW_DATA_LOSS)

Для Ms SQL 2005

DBCC REBUILD_LOG('имя_базы', '<имя нового лога c полным путем>')
GO
Use master
GO
ALTER DATABASE <Имя БД> SET SINGLE_USER
GO
USE имя_базы
GO
DBCC CHECKDB('имя_базы', REPAIR_ALLOW_DATA_LOSS)

/*ищет лог по старому пути. И если база уже перенесена на другую машину, то надо на время создать пустой лог в той же директории и на том же диске, что и был раньше. После восстановления его можно перенести (детач-аттач с новыми путями)*/

Если Вам не удалось перевести базу в single user mode, то для проверки целостности данных можно попробовать dbo only mode.

Если же, база в single user mode, то НЕ выполнять следующую строку

sp_dboption '<db_name>', 'dbo use only', 'true'

Далее  

Для Ms SQL 2000

GO
sp_dboption '<db_name>', 'single_user', 'false'
GO
USE master
GO -- запрещаем изменения в системных базах
sp_configure 'allow updates', 0
GO

Для Ms SQL 2005 

GO
alter database <db_name> set multi_user
GO
USE master
GO --запрещаем изменения в системных базах

Полезные  странички:
Администратору 1С SQL
Восстановление 1C SQL