Линукс кое где догнал винду. Есть федора38, воткнут USB диск: /dev/sdc2 -> /home/aik/share/photos-black.
Пытаюсь расшарить и не работает никак. И тулзы не выдают внятной диагностики.
Здравствуйте, aik, Вы писали:
aik>На старых линуксах работало. selinux и firewalld выключены. А как вы шарите папки? Не sshfs же (который работает, но мммм небыстро)?
Я шарю по NFS-у. Раздаю торрентские файлы проигрывателю кино, который у меня тоже линух с xbmc (kodi).
На сервере у меня 40-я федора, на клиенте какая-то доисторическая (примерно 16-я, наверное). Пару федор назад они сломали NFS через UDP, и я с наскоку не починил. Пришлось на TCP перейти. Раздражает немного то, что при первое обращение теперь несколько секунд занимает. Но не настолько раздражает, чтобы преодолеть лень и доразобраться.
Косвенно это стало понятно из логов NFS клиента и сервера.
aik>На старых линуксах работало. selinux и firewalld выключены. А как вы шарите папки? Не sshfs же (который работает, но мммм небыстро)?
Samba для клиентов MS Windows, NFS для *nix.
FTP тоже вариант, как и sshfs.
Здравствуйте, 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 видны команды запросов и ответов. Можно будет увидеть, на каком конкретно запросе всё рушится, и, опять же, без гарантии, но мне это пару раз помогало сообразить, где собака зарыта или хотя бы в каком направлении можно потыкать палочкой.
M>Косвенно это стало понятно из логов NFS клиента и сервера.
Я так делал, получаю:
exportfs: /home/aik/share/photos-black does not support NFS export
Без деталей. Гугль говорит что это exfat виноват, типа он не умеет "s_export_op", делай ext4. Я эту логику не понимаю, но, видимо, nfs не судьба в данном случае. Хым. Буду пинать cifs дальше.
aik>Без деталей. Гугль говорит что это exfat виноват, типа он не умеет "s_export_op", делай ext4. Я эту логику не понимаю, но, видимо, nfs не судьба в данном случае. Хым. Буду пинать cifs дальше.
а, exFAT...
Кстати для полноты информации стоить упомянуть NBD (network block device). Очень простой способ расшарить блочное устройство.
Здравствуйте, CaptainFlint, Вы писали:
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". CF>Дебажить самбу — крайне неблагодарное занятие, увы. Разумеется, стоит для начала перепроверить самые очевидные идиотские моменты: что IP введён без ошибок, что серверу неожиданно не прилетел новый адрес по DHCP, что мы вообще можем подключиться к серверу по другим протоколам-портам; убедиться, что самба-демон не сдох…
Не, не то. Ну, добился я STATUS_ACCESS_DENIED. Шарю я /home/aik/share, которая drwxrwxrwx. Но, поскольку /home/aik — drwxr-x---+ (т.е. everyone не имеет разрешений) — не работает. Перенес шару в /home/share (drwxrwxrwx.), заработало. Наверное, логично, но "smbclient --user=aik" почему то не идентифицировал корректно юзера на сервере, и его записали в гости. А, фиг с ним, в другой раз доотлажу.
Здравствуйте, m2user, Вы писали:
M>Кстати для полноты информации стоить упомянуть NBD (network block device). Очень простой способ расшарить блочное устройство.
И насколько просто убить этот самый exfat по сетке?
M>>Кстати для полноты информации стоить упомянуть NBD (network block device). Очень простой способ расшарить блочное устройство.
aik>И насколько просто убить этот самый exfat по сетке?
Не задумывался
Если есть опасения, то там есть опция readonly.
Здравствуйте, aik, Вы писали:
aik>Наверное, логично, но "smbclient --user=aik" почему то не идентифицировал корректно юзера на сервере, и его записали в гости. А, фиг с ним, в другой раз доотлажу.
У самбы отдельная настройка юзеров. Она, кажется, вообще по умолчанию с системными пользователями никак не пересекается, а держит свою отдельную базу, в которой надо юзеров заводить через smbpasswd.