Сообщение Re: Расшарить примонтированный диск по сети от 04.12.2024 18:55
Изменено 04.12.2024 18:59 CaptainFlint
Re: Расшарить примонтированный диск по сети
Здравствуйте, aik, Вы писали:
aik>Линукс кое где догнал винду. Есть федора38, воткнут USB диск: /dev/sdc2 -> /home/aik/share/photos-black.
aik>Пытаюсь расшарить и не работает никак. И тулзы не выдают внятной диагностики.
aik>"sudo mount -t cifs -o user=aik //192.168.10.104/media hass-share-cifs/" -> "CIFS: VFS: BAD_NETWORK_NAME: \\192.168.10.104\media".
Дебажить самбу — крайне неблагодарное занятие, увы. Разумеется, стоит для начала перепроверить самые очевидные идиотские моменты: что IP введён без ошибок, что серверу неожиданно не прилетел новый адрес по DHCP, убедиться, что самба-демон не сдох… Дальше я бы попробовал через smbclient посмотреть листинг шар, чтобы выяснить, беда в доступе к конкретной шаре или к серверу в целом.
Затем можно включить повышенный verbose на сервере, попытаться подконнектиться, и попытаться найти в логах соответствующую информацию: получил ли сервер вообще запрос, если получил, то как отреагировал, есть ли какие-то ошибки на стороне сервера. Чаще всего эти ошибки оказываются абсолютно невразумительными, но идентифицировав их, можно повысить уровень verbose до максимума, воспроизвести снова и поискать ту же самую ошибку, чтобы посмотреть, какие вообще операции там рядом выполняются. Иногда это помогает угадать возможные причины.
Также можно запустить Wireshark/tcpdump и помониторить трафик. Протокол SMB не слишком замороченный, в нём в plain text видны команды запросов и ответов. Можно будет увидеть, на каком конкретно запросе всё рушится, и, опять же, без гарантии, но мне это пару раз помогало сообразить, где собака зарыта или хотя бы в каком направлении можно потыкать палочкой.
aik>Линукс кое где догнал винду. Есть федора38, воткнут USB диск: /dev/sdc2 -> /home/aik/share/photos-black.
aik>Пытаюсь расшарить и не работает никак. И тулзы не выдают внятной диагностики.
aik>"sudo mount -t cifs -o user=aik //192.168.10.104/media hass-share-cifs/" -> "CIFS: VFS: BAD_NETWORK_NAME: \\192.168.10.104\media".
Дебажить самбу — крайне неблагодарное занятие, увы. Разумеется, стоит для начала перепроверить самые очевидные идиотские моменты: что IP введён без ошибок, что серверу неожиданно не прилетел новый адрес по DHCP, убедиться, что самба-демон не сдох… Дальше я бы попробовал через smbclient посмотреть листинг шар, чтобы выяснить, беда в доступе к конкретной шаре или к серверу в целом.
Затем можно включить повышенный verbose на сервере, попытаться подконнектиться, и попытаться найти в логах соответствующую информацию: получил ли сервер вообще запрос, если получил, то как отреагировал, есть ли какие-то ошибки на стороне сервера. Чаще всего эти ошибки оказываются абсолютно невразумительными, но идентифицировав их, можно повысить уровень verbose до максимума, воспроизвести снова и поискать ту же самую ошибку, чтобы посмотреть, какие вообще операции там рядом выполняются. Иногда это помогает угадать возможные причины.
Также можно запустить Wireshark/tcpdump и помониторить трафик. Протокол SMB не слишком замороченный, в нём в plain text видны команды запросов и ответов. Можно будет увидеть, на каком конкретно запросе всё рушится, и, опять же, без гарантии, но мне это пару раз помогало сообразить, где собака зарыта или хотя бы в каком направлении можно потыкать палочкой.
Re: Расшарить примонтированный диск по сети
Здравствуйте, aik, Вы писали:
aik>Линукс кое где догнал винду. Есть федора38, воткнут USB диск: /dev/sdc2 -> /home/aik/share/photos-black.
aik>Пытаюсь расшарить и не работает никак. И тулзы не выдают внятной диагностики.
aik>"sudo mount -t cifs -o user=aik //192.168.10.104/media hass-share-cifs/" -> "CIFS: VFS: BAD_NETWORK_NAME: \\192.168.10.104\media".
Дебажить самбу — крайне неблагодарное занятие, увы. Разумеется, стоит для начала перепроверить самые очевидные идиотские моменты: что IP введён без ошибок, что серверу неожиданно не прилетел новый адрес по DHCP, что мы вообще можем подключиться к серверу по другим протоколам-портам; убедиться, что самба-демон не сдох… Дальше я бы попробовал через smbclient посмотреть листинг шар, чтобы выяснить, беда в доступе к конкретной шаре или к серверу в целом.
Затем можно включить повышенный verbose на сервере, попытаться подконнектиться, и попытаться найти в логах соответствующую информацию: получил ли сервер вообще запрос, если получил, то как отреагировал, есть ли какие-то ошибки на стороне сервера. Чаще всего эти ошибки оказываются абсолютно невразумительными, но идентифицировав их, можно повысить уровень verbose до максимума, воспроизвести снова и поискать ту же самую ошибку, чтобы посмотреть, какие вообще операции там рядом выполняются. Иногда это помогает угадать возможные причины.
Также можно запустить Wireshark/tcpdump и помониторить трафик. Протокол SMB не слишком замороченный, в нём в plain text видны команды запросов и ответов. Можно будет увидеть, на каком конкретно запросе всё рушится, и, опять же, без гарантии, но мне это пару раз помогало сообразить, где собака зарыта или хотя бы в каком направлении можно потыкать палочкой.
aik>Линукс кое где догнал винду. Есть федора38, воткнут USB диск: /dev/sdc2 -> /home/aik/share/photos-black.
aik>Пытаюсь расшарить и не работает никак. И тулзы не выдают внятной диагностики.
aik>"sudo mount -t cifs -o user=aik //192.168.10.104/media hass-share-cifs/" -> "CIFS: VFS: BAD_NETWORK_NAME: \\192.168.10.104\media".
Дебажить самбу — крайне неблагодарное занятие, увы. Разумеется, стоит для начала перепроверить самые очевидные идиотские моменты: что IP введён без ошибок, что серверу неожиданно не прилетел новый адрес по DHCP, что мы вообще можем подключиться к серверу по другим протоколам-портам; убедиться, что самба-демон не сдох… Дальше я бы попробовал через smbclient посмотреть листинг шар, чтобы выяснить, беда в доступе к конкретной шаре или к серверу в целом.
Затем можно включить повышенный verbose на сервере, попытаться подконнектиться, и попытаться найти в логах соответствующую информацию: получил ли сервер вообще запрос, если получил, то как отреагировал, есть ли какие-то ошибки на стороне сервера. Чаще всего эти ошибки оказываются абсолютно невразумительными, но идентифицировав их, можно повысить уровень verbose до максимума, воспроизвести снова и поискать ту же самую ошибку, чтобы посмотреть, какие вообще операции там рядом выполняются. Иногда это помогает угадать возможные причины.
Также можно запустить Wireshark/tcpdump и помониторить трафик. Протокол SMB не слишком замороченный, в нём в plain text видны команды запросов и ответов. Можно будет увидеть, на каком конкретно запросе всё рушится, и, опять же, без гарантии, но мне это пару раз помогало сообразить, где собака зарыта или хотя бы в каком направлении можно потыкать палочкой.