Проблема в следующем: на сервере установлен ltsp-server-standalone, все вроде настроил, но у nbd-client не выходит считать информацию с /dev/nbd0, хотя на сервере я вижу, что образ /opt/ltsp/images/amd64.img успешно транслируется. Вопрос: как можно проверить, что конкретно вызывает ошибку? Kernel 4.15, server Ubuntu 18.04, клиентский образ - 18.04,nbd-client 3.16,3.18

На работе менеджеры сидят на толстых клиентах. ОС Kubuntu 14.04. Заметил такую странность : Захожу из под одного пользователя, ввожу команду cat /etc/passwd | grep operat* а в ответ тишина. Ввожу то же самое без астериска cat /etc/passwd | grep operat и grep отдает мне требуемую строчку с именем пользователя operator_41. Так же команда cat /etc/passwd | grep ssh* выдает строки с паттерном ss(sshd и messagebus), а команда cat /etc/passwd | grep ssh выдает только sshd. (тут возможно я не до конца разобрался с тем как grep работает с *) При логине через другого пользователя команды cat /etc/passwd | grep operat* cat /etc/passwd | grep operat отрабатывает как надо, возвращая строку с пользователем. Шелл в обох случаях bash. Куда смотреть? Чем эти пользователи могут отличаться?

Здраствуйте. На работе такая проблема - есть сервер ltsp и толстые клиенты, которые к нему подключаются. На сервере у каждого пользователя есть своя домашняя папка, которая монтируется в толстый клиент. Неделю назад начала возникать ошибка у некоторых пользователей - отваливается смонтированная домашняя папка. Выяснилось, что происходит это при работе с Google Chrome. При чем если запустить чистый сеанс Хрома, без восстановления вкладок - все работает отлично. Если же сделать восстановление - через некоторое время Хром падает с segfault потому что не может получить доступ к домашней папке. Саму точку монтирования видно, но Владелец и группа обозначены знаками вопроса. Chrome версии 64, клиентская OS Ubuntu 14.04 3.13.0.

Сразу оговорюсь - из 40 сотрудников данная проблема зафиксирована у 3-х.

Суть вопроса вот в чем - как можно отследить, что конкретно вызывает сбой?