Failed to mount parsec file system astra linux

Failed to mount parsec file system astra linux

Здравствуйте.
Имеется клиент Astra Linux 1.7.3 включённый в домен Windows с помощью sssd. Есть выделенный файл-сервер доменный. В соответствии с wiki: https://wiki.astralinux.ru/pages/viewpage.action?pageId=4489. организовано подключение разделяемых ресурсов сервера. Т.е. установлены пакеты cifs-utils и libpam-mount, изменён под меня /etc/security/pam_mount.conf.xml:

See pam_mount.conf(5) for a description.
—>

since this file is still processed in a single pass
from top-to-bottom —>

mount.cifs //%(SERVER)/%(VOLUME) %(MNTPT) -o %(OPTIONS)

fstype=»cifs»
server=»fserver.domain.ru»
path=»asu1″
mountpoint=»~/asu1″
options=»user=%(USER),uid=%(USER),rw,cruid=%(USER),sec=krb5i,file_mode=0770,dir_mode=0770,vers=3.0″
/>

fstype=»cifs»
server=»fserver.domain.ru»
path=»asu2″
mountpoint=»~/asu2″
options=»user=%(USER),uid=%(USER),rw,cruid=%(USER),sec=krb5i,file_mode=0770,dir_mode=0770,vers=3.0″
/>

fstype=»cifs»
server=»fserver.domain.ru»
path=»appl1″
mountpoint=»~/appl1″
options=»user=%(USER),uid=%(USER),rw,cruid=%(USER),sec=krb5i,file_mode=0770,dir_mode=0770,vers=3.0″
/>

—>

You will need to explicitly initialize it with the empty string
to reset the defaults to nothing. —>

—>

—>

—>

Также внесены следующие изменения:
В файле /etc/pam.d/fly-dm дописана строка session optional pam_mount.so сразу после session required pam_parsec_mac.so
В файле /etc/pam.d/login дописал строку session optional pam_mount.so сразу после session required pam_parsec_mac.so
Также добавлена строка auth optional pam_mount.so сразу после auth requisite pam_nologin.so
В файле /etc/pam.d/passwd добавлена строку password optional pam_mount.so сразу после password required pam_parsec_mac.so Т.к. уже не первый день вожусь, то для предотвращения попытки монтирования сетевых ресурсов до поднятия сети запущены:
sudo systemctl enable systemd-networkd-wait-online sudo systemctl enable systemd-networkd.service sudo systemctl enable NetworkManager-wait-online.service Более того, для уверенности, что DNS уже пришёл в себя на клиенте создал файл:
/usr/lib/NetworkManager/conf.d/20-connectivity.conf с содержимым:

[connectivity]
uri=https://

Но всё равно монтирование сетевых дисков не стабильно. Иногда подключаются при входе все три. Иногда пара или только один. Иногда ни одного ресурса. В auth.log соответственно всегда примерно одно и то же:

Feb 1 11:59:49 ws-10003 fly-dm[1103]: :0[1103]: (mount.c:659): Password will be sent to helper as-is.
Feb 1 11:59:49 ws-10003 fly-dm[1103]: :0[1103]: command: ‘mount.cifs’ ‘//fserver.domain.ru/appl1’ ‘/home/user_a@domain.ru/drv_y’ ‘-o’ ‘user=user_a,domain=domain,rw,setuids,perm,soft,iocharset=utf8,cruid=user_a,sec=krb5i,file_mode=0777,dir_mode=0777,vers=2.0’
Feb 1 11:59:49 ws-10003 fly-dm[1103]: :0[1103]: (mount.c:72): Messages from underlying mount program:
Feb 1 11:59:49 ws-10003 fly-dm[1103]: :0[1103]: (mount.c:76): mount error(101): Network is unreachable

ws-10003 fly-dm[1103]: :0[1103]: (pam_mount.c:522): mount of appl1 failed

Как добиться стабильности автомонтирования? Может вообще пойти путём создания юнита пользовательского уровня, чтобы он стартовал когда уже поднимется графический интерфейс? И как тогда быть с уже внесёнными изменениями?

Читайте также:  Linux list archive files
  • gt оверквотинг удален Платная поддержка самой продаваемой нацОС там — , Грузин (?), 20:33 , 02-Фев-23, ( 1 )
  • а случайно какой-нибудь 802 1x в сети не используется , Ann None (?), 20:37 , 02-Фев-23, ( 2 )
    • А кто его знает За эту инфраструктуру главк отвечает , alexy (ok), 10:45 , 03-Фев-23, ( 3 )

    >[оверквотинг удален]
    > Feb 1 11:59:49 ws-10003 fly-dm[1103]: :0[1103]: (mount.c:72): Messages from underlying
    > mount program:
    > Feb 1 11:59:49 ws-10003 fly-dm[1103]: :0[1103]: (mount.c:76): mount error(101): Network
    > is unreachable
    >

    > Ну и потом где-то ниже по журналу:
    >

    ws-10003 fly-dm[1103]: :0[1103]: (pam_mount.c:522): mount of appl1 failed

    > Как добиться стабильности автомонтирования? Может вообще пойти путём создания юнита пользовательского
    > уровня, чтобы он стартовал когда уже поднимется графический интерфейс? И как
    > тогда быть с уже внесёнными изменениями?

    Платная поддержка самой продаваемой нацОС там ->

    > а случайно какой-нибудь 802.1x в сети не используется?

    А кто его знает?! За эту инфраструктуру главк отвечает.

    смотри man pam_mount там определенный порядок расписан, зачем и почему. Хотя это и не поможет для
    «Network is unreachable».

    Поставьте заббикс или попроще для сбора сетевой статистики, может у вас действительно «Network is unreachable».

    У нетворк-манагера есть бага. Когда на сервере более 1 сетевого интерфейса, в одном из них линк есть, в другом нет. Он некорректно отдаёт метрику «network is ready» при загрузке. А далее системда, которая грузит всё параллельно, начинает поднимать сетевые сервисы, которые падают, потому что сеть на самом деле ещё не готова.

    Источник

    При обновлении системы 1.6 из 20191029SE16.iso, возникают ошибки.

    Добрый день!
    Пытаюсь обновить Astra Linux SE 1.6. из 20191029SE16.iso но в процессе выполнения получаю ошибки:

    Обрабатываются триггеры для libvlc-bin:amd64 (3.0.8-0+deb9u1astra1) …
    Обрабатываются триггеры для parsec-base (2.5.286) …
    При обработке следующих пакетов произошли ошибки:
    bind9-host
    libk3b7
    libisc169:amd64
    libisccc160:amd64
    libbind9-160:amd64
    k3b
    compton
    xserver-xephyr
    xserver-xorg-core
    fly-launcher
    flyui-utils
    xserver-xorg
    libisccfg160:amd64
    fly-qdm
    libdns1100:amd64
    liblwres160:amd64
    xorg
    parsec-kiosk2
    xserver-xorg-video-intel
    fly-admin-kiosk
    k3b-i18n
    fly-admin-local
    fly-wm
    fly-admin-local-se
    fly-admin-wm
    xserver-xorg-input-evdev
    parsec-sumac
    fly-admin-digsig
    fly-wm-decor
    fly-dm
    fly-admin-dm
    xserver-xorg-input-all
    E: Sub-process /usr/bin/dpkg returned an error code (1)

    Последовательность действий при обновлении следующая:
    1. Загружаю образ диска с обновлениями по ссылке: http://dl.astralinux.ru/astra/stable/smolensk/security-updates/1.6/20191029SE16/20191029SE16.iso в директорию /mnt/
    2. Проверяю контрольную сумму gostsum -d /mnt/20191029SE16.iso и в ответ получаю 167f94ce19294bb47b69bb16eda160f41ba2346c9db2a7f749a9a80da64b3a07 —
    3. Маплю ISO к сидирому:

    Пакеты устанавливаются, но потом установка прерывается из-за ошибки выше.

    После перезагрузки не могу подключиться по ssh, вижу ошибку

    При попытке входа на саму машину с ОС, вместо GUI вижу консоль и предложение ввести логин, пароль и integrity level. Ввожу логин, пароль, а левел устанавливаю 63. После ввода повторно предлагает ввести всё заново.

    В чем может быть проблема?

    Система чистая, только после установки на сервер.

    cogniter

    Moderator

    1. выполняйте обновление строго по инструкции
    2. проверьте, какие опции безопасности включены на момент начала обновления

    qwas

    New member

    1. выполняйте обновление строго по инструкции
    2. проверьте, какие опции безопасности включены на момент начала обновления

    Добрый день!
    Вы имеете ввиду инструкцию https://wiki.astralinux.ru/pages/viewpage.action?pageId=61571683 ?
    Разъясните, пожалуйста, некоторые моменты инструкции.

    Во втором пункте инструкции сказано:

    Обновление безопасности подписано усиленной квалифицированной электронной подписью АО «НПО РусБИТех» с использованием ключевого комплекта, выданного удостоверяющим центром Министерства Обороны Российской Федерации (Скачать).
    Для проверки подписи необходимо добавить в локальное хранилище сертификаты головного удостоверяющего центра и списки отозванных сертификатов, размещенные на сайте: https://structure.mil.ru/structure/UC/certificate.htm

    Если проверка контрольной суммы образа проходит успешно, и я получаю контрольную сумму, следует ли выполнять это требование? Если да, то в какую директорию добавлять ключевой комплект (Скачать) и что с ним делать после добавления? Какая директория является локальным хранилищем для сертификатов головного удостоверяющего центра?

    Внимание
    Обновление операционной системы необходимо выполнять от имени учетной записи пользователя с полномочиями администратора системы с высоким уровнем целостности.
    На время установки обновления необходимо снять запрет на установку бита исполнения в политиках безопасности.
    Для полного завершения обновления потребуется установочный диск операционной системы специального назначения «Astra Linux Special Edition» РУСБ.10015-01 (версия 1.6)

    Установку выполняю от администратора созданного на этапе установки ОС. Подключен к серверу по ssh. Если не ошибаюсь, то в режиме оболочки, администратору автоматически устанавливается высокий уровень целостности (63), верно? Запрет на установку бита исполнения не установлен, в файле /parsecfs/nochmodx установлен 0.

    В остальном моя установка соответствует инструкции, или я что-то пропустил?

    Заранее спасибо за помощь!

    Источник

    Как исправить “failed to mount /etc/fstab” в Linux

    В этой статье я расскажу, как решить проблему «failed to mount /etc/fstab» в Linux.

    В рассматриваемом файле содержится описательная информация о файловых системах, которые система может смонтировать автоматически во время загрузки.

    Эта информация является статической и считывается другими программами в системе, такими как mount, umount, dump и fsck.

    Он имеет шесть важных спецификаций для установки файловой системы: первое поле описывает блокировку специального устройства или удаленной файловой системы, второе поле определяет точку монтирования для файловой системы, а третья – тип файловой системы.

    Четвертое поле определяет параметры монтирования, связанные с файловой системой, а пятое поле считывается инструментом дампа. Последнее поле используется инструментом fsck для определения порядка проверки файловой системы.

    Четвертое поле определяет параметры монтирования, связанные с файловой системой, а пятое поле считывается инструментом дампа.

    Последнее поле используется инструментом fsck для определения порядка проверки файловой системы.

    После редактирования /etc/fstab для создания automount и перезагрузки моей системы; Linux загрузился в аварийный режим, показывая сообщение об ошибке:

    Я зарегистрировался как root из интерфейса выше и набрал следующую команду, чтобы просмотреть журнал systemd

    Как вы можете видеть, основная ошибка (отказ модуля etc-fstab.mount) приводит к нескольким другим ошибкам (проблемы с зависимостью системы systemd), такие как отказ локального -fs.target, rhel-autorelabel-mark.service и т. д.

    Причины ошибки

    Приведенная выше ошибка может возникнуть из-за любой из нижеперечисленных проблем в файле /etc/fstab:

    • отсутствует файл / etc / fstab
    • неправильная спецификация параметров монтирования файловой системы,
    • сбой точек монтирования или непризнанные символы в файле.

    Чтобы решить эту проблему, вы можете использовать исходный файл, если создали резервную копию, иначе закомментируйте любые изменения, сделанные вами с помощью символа «#» (а также убедитесь, что все строки без комментирования – строки монтирования файловой системы).

    Я понял, что набрал буква «r» в начале файла, как показано на скриншоте выше – это было признано системой как специальное устройство, которое фактически не существовало в файловой системе, что привело к появлению последовательных ошибок.

    Мне потребовалось несколько часов, прежде чем заметить и исправить это.

    Поэтому мне пришлось удалить лишнюю букву,закомментировать первую строку в файле, закрыть и сохранить его.

    После перезагрузки система снова загрузилась.

    Как избежать таких проблем в будущем

    Чтобы избежать возникновения таких проблем в вашей системе, обратите внимание на следующее:

    Всегда создавайте резервную копию своих файлов конфигурации перед их редактированием.

    В случае каких-либо ошибок в ваших конфигурациях вы можете вернуться к файлу по умолчанию / работе.

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

    Используйте эти утилиты, где это возможно.

    Однако, если вы получаете сообщения о системных ошибках:

    Сначала просмотрите журнал systemd с помощью утилиты journalctl, чтобы определить, что именно вызвало их:

    Источник

Оцените статью
Adblock
detector