или как не дать маку и другим клиентам писать назойливые .DS_Store и Thumbs.db на файловый сервер.

Решается все достаточно просто - для этого существует директива veto files в конфиге самбы, она может быть установлена глобально или отдельно на каждую шару, вот пример из моего конфига:

veto files = /._*/.DS_Store/.T*/Thumbs.db/Network Trash Folder/Temporary Items
delete veto files = yes

И после рестарта самбы рекомендуется зачистить сервер от такого рода файлов командой

find /path/to/samba/shares \( -name ._* -or -name .DS_Store -or -name .T* -or -name Thumbs.db \) -delete

find /path/to/samba/shares -type d \( -name "Network Trash Folder" -or -name "Temporary Items" \) -exec rm -rf {} +

После этого проблема закрыта.

Справочный материал:

• Disable creation of .DS_Store files on samba shares
  
• Samba veto files (S)
  
• Samba delete veto files (S)
• Remove Netatalk “Network Trash Folder”
• How to delete directories based on 'find' output?

PS Так же на стороне мака можно запретить создание подобного рода файлов на сетевых носителях и прочих примонтированных устройствах командой

defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool true

Но по отзывам это применимо не ко всем Mac OS, из быстро-гуглинга так и не понял у кого работает, а у кого нет, но официальный саппорт apple рекомендует именно такой способ.

Речь пойдет об ошибке подключения к сетевому ресурсу в windows, а именно:

Множественное подключение к серверу или разделяемым ресурсам одним пользователем с использованием более одного имени пользователя не разрешено. отключите все предыдущие подключения к серверу или разделяемым ресурсам и повторите...

Возникает она в случае, если вы подключены к общему ресурсу с одними учетными данными и пытаетесь подключиться к другому ресурсу на том же сервере но с другими учетными данными, а сервер (в моем случае Samba) настроен в режиме security = USER.

Немного подробнее о security = USER

Пример security устанавливает "security mode bit" в репликах к smbd в момент согласования протокола, тем самым включая или отключая режим безопасности. Клиенты, основываясь на этой информации, определяют нужно ли (и если да то как) передавать серверу имя пользователя и пароль.

При security = USER, клиент должен сначала произвести вход (logon), с существующим именем пользователя и паролем (имя может быть транслировано с помощью параметра username map). Шифрованные пароли (см. encrypted passwords) также могут быть использованы в этом режиме.

Заметьте, что имя запрошенного ресурса не будет послано серверу до тех пор, пока сервер не аутентифицирует клиента. Именно поэтому гостевые учетки не работают в режиме USER, не позволяя серверу преобразовывать неопознанных пользователей в гостей.

Есть одна ошибка в Windows для рабочих групп (Windows for Workgroups, WfWg), которая имеет отношение к этому параметру. При работе в режиме USER или SERVER, клиенты Windows для рабочих групп игнорируют имя пользователя и пароль, указываемые в диалоге для доступа к ресурсу. "Благодаря" этому практически невозможно присоединиться к сервису Samba пользователем, отличным от того, с правами которого произведен вход в Windows.

Решение проблемы

Гениально простое решение предлагает нам M$: подключиться к серверу не по имени, а по IP. Действительно просто и замечательно работает :)

Предшествующая статья "Бесшумный компьютер часть 2: крутой моддинг".

Пробный пуск был удачным, но не все пошло как планировалось.

Во-первых, для запуска пришлось все разворотить и сделать компьютер в стиле "кишки наружу", потому что блок питания найти так и не удалось и пришлось использовать стандартный большой.