mount error(121): Remote I/O error

В Linux, при попытке монтирования по локальной сети Windows-папки с общим доступом, отображается следующая ошибка:
CIFS VFS: cifs_mount failed w/return code = -121
mount error(121): Remote I/O error
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

Проблема находится на стороне Windows и решается путём правки значений реестра:
записи HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\LargeSystemCache устанавливаем значение 1;
записи HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\Size устанавливаем значение 3.

Proxmox — расширение хранилища

При развёртывании в виртуальной машине Proxmox VE (на чистую машину), в процессе использования, место хранилища под KVM закончилось. Потребовалось увеличить выделенное место жесткого диска для виртуальной машины с Proxmox. После увеличения выделенного места, путём изменения настроек виртуальной машины, встаёт необходимость произвести расширение файловой системы, используемой Proxmox. При попытке выполнить задачу, у пользователей могут возникать следующие ошибки:

  • The util fdisk doesn’t support GPT. Use GNU Parted
  • resize2fs: Device or resource busy while trying to open /dev/sda3
  • Insufficient free space: 1 extents needed, but only 0 available with 32.83g available.


Порядок выполнения действий:

  1. Остановим виртуальные машины: qm shutdown all
  2. Размонтируем логический том хранилища KVM: umount /var/lib/vz
  3. Запустим редактор разделов для жесткого диска sda: parted /dev/sda
  4. Командой resizepart 3 увеличим размер раздела lvm.
  5. Увеличим размер физического диска LVM: pvresize /dev/sda3.
  6. Увеличим размер логического диска LVM: lvextend /dev/pve/data -l +100%FREE
  7. Увеличим размер файловой системы логического диска: resize2fs /dev/pve/data
  8. Проверим и исправим файловую систему: fsck -f /dev/mapper/pve-data
  9. Монтируем том хранилища: mount /var/lib/vz
  10. Перезагрузим систему: reboot

При нестандартных настройках разделов диска:

  • Список дисков и их разделов выводится командой fdisk -l.
  • Номера разделов в программе parted выводятся командой print. Нас интересует номер раздела lvm.
  • Список физических дисков LVM выводится командой pvdisplay.
  • Список логических дисков LVM выводится командой lvdisplay.
  • Список файловых систем выводится командой df -h.

Exim4/Postfix: Network is unreachable

В журнале Exim4 или Postfix периодически появляются записи вида: aspmx.l.google.com [2a00:1450:4010:c08::1b] Network is unreachable.
Используемый MTA (Exim4 или Postfix) пытается подключиться к SMTP Google по протоколу IPv6, но этого не удаётся сделать, по причине отсутствия поддержки IPv6 в используемой сети или конфигурации сетевых интерфейсов.
Для решения проблемы, требуется отключить использование протокола IP 6 версии.
Для Exim4, конфигурационном файле /etc/exim4/exim4.conf.template, в начале файла, перед секцией begin acl необходимо вписать:

disable_ipv6 = true

После чего, необходимо перезагрузить Exim4 командой /etc/init.d/exim4 restart.
Для Postfix, конфигурационном файле /etc/postfix/main.cf, необходимо отредактировать директиву:

inet_protocols = ipv4

После чего, необходимо перезагрузить Postfix командой /etc/init.d/postfix restart.

P.S.: Если Вы всё таки решите задействовать протокол IPv6, не забудьте указать свой IPv6 адрес в DNS записях, чтобы не возникло проблемы с прохождением проверки SPF-записи.

gem: unable to convert U+00A9 from UTF-8 to US-ASCII

При использовании команды gem install, отображаются сообщения о пропуске установки файлов Ruby из-за ошибки конвертации символов из таблицы UTF-8 в US-ASCII.
Вероятнее всего, в системе не была выставлена подходящая кодировка. В этом случае решить проблему можно, выбрав в качестве используемой кодировки ru_RU.UTF-8, используя команду:

dpkg-reconfigure locales

Exim4 — Не доходит отправляемая почта

В журнале Exim4 /var/log/exim4/mainlog постоянно пополняются записи:

Our system has detected an unusual rate of\n421-4.7.0 unsolicited mail originating from your IP address. To protect our\n421-4.7.0 users from spam, mail sent from your IP address has been temporarily\n421-4.7.0 rate limited.

Сие говорит о том, что сервер-получатель отвергает корреспонденцию из-за подозрения на спам (слишком частые отправления писем). Следует отследить в журнале почтовые адреса, от имени которых отправляются письма. Если почтовые адреса отправителей Вам не известны, то скорее всего вредоносный код генерирует рассылку, от имени несуществующих почтовых адресов, подключенных доменов.
Следует посмотреть объем неотправленных сообщений в директории /var/spool/exim4/input. Если сообщения содержат спам и их объём велик — следует выявить вредоносный код, генерирующий эти письма.
К примеру, если сервер используется для работы сайтов, написанных на PHP, то для обнаружения вредоносного кода следует изучить журнал /var/log/php-mail.log. По количеству генерируемых сообщений, обнаружить вредный сценарий довольно просто.
После устранения источника проблемы, следует остановить почтовый сервер командой killall -9 exim4 (команда service exim4 stop вероятнее всего не прервёт процесс отправки замороженных почтовых сообщений). И затем очистить директорию со скопившейся корреспонденцией, командой find /var/spool/exim4/input -delete. После чего, почтовый сервер можно запустить вновь: service exim4 start.
Для пресечения подобной проблемы в будущем, можно ограничить список адресов, корреспонденция с которых будет отправляться сервером Exim4.

GPG error — NO_PUBKEY

Бывают случаи, когда при выполнении команды apt-get update, выводится ошибка, где упоминается GPG:

W: A error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://www.deb-multimedia.org stable Release: The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY 5C808C2B65558117

Номер публичного ключа при этом может быть иным.
Решением проблемы является добавление в систему публичного GnuPG-ключа репозитория, из которого осуществляется попытка установить пакет (который, в свою очередь, подписан данным ключом):

gpg --keyserver pgpkeys.mit.edu --recv-key 5C808C2B65558117
gpg -a --export 5C808C2B65558117 | apt-key add -

Disk quota exceeded при наличии свободного места

Порой при работе сайта на арендованном VPS может появиться подобная ошибка:

Warning: mkdir(): Disk quota exceeded
in /var/www/site.ru/logger.php
on line XXX Can’t log exception

Работа сайта может быть нарушена при обращениях к БД. Сама БД при перезагрузке может выдавать ошибку:

mysql open: Disk quota exceeded

Аналогичную ошибку при запуске могут выдавать и все остальные программы.
Если при проверке наличия свободного места (команда df -h) мы видим, что свободного места ещё достаточно, то вероятно дело в ограничении максимального количества дескрипторов, установленных хостером. Следует обратиться в службу технической поддержки, уточнить, подошли ли Вы к пределу количества инод, и если это так, то попросить увеличить лимит. После этого попытаться заново запустить все необходимые службы.

SSHD — POSSIBLE BREAK-IN ATTEMPT!

Запись в журнале /var/log/auth.log вида

sshd[16793]: Address XXX.XXX.XXX.XXX maps to somedomain.com, but this does not map back to the address — POSSIBLE BREAK-IN ATTEMPT!

говорит о том, что при попытке проверить обратное сопоставление домена, полученный IP-адрес отличается от IP-адреса клиента SSH.
Это вполне распространённая ситуация, например: сервер А обслуживает домен somedomain.com и использует его в качестве своего имени, сам сайт somedomain.com физически находится на сервере Б; сервер А пытается подключиться к серверу С; сервер С проводя обратное сопоставление доменного имени клиента видит, что у домена somedomain.com должен быть IP-адрес сервера Б, который отличается от IP-адреса сервера А.
Данная запись может служить поводом для блокировки клиента, например программой fail2ban. Если IP-адрес XXX.XXX.XXX.XXX, указанный в записи журнала, является доверенным, а программа защиты блокирует этот адрес под предлогом спуфинга, то данную проблему можно решить добавив в файл конфигурации /etc/ssh/sshd_config строку (или отредактировав, при её наличии):

UseDNS no

Альтернативным способом отключения блокировок является правка фильтров программы защиты, например всё той же fail2ban, то есть исключение вышеуказанной фразы о взломе из регулярных выражений фильтров.

Open file limits

Часто при использовании какой-либо программы, при открытии большого количества файлов она сваливается, т.к. упирается в ограничение (по умолчанию 1024 открытых файла), выводя ошибку: failed (24: Too many open files). Текущее использование открытых файлов программой можно узнать так:

lsof -u процесс | wc -l

Многие программы умеют изменять ограничения самостоятельно, поэтому задать ограничение на количество открытых файлов можно в конфигурационном файле. Например, используя параметр open_files_limit в конфигурационном файле my.cnf сервера MySQL, или параметр worker_rlimit_nofile для Nginx.
Однако, заданные значения в конфигурационных файлах этих программ могут не применяться при перезапуске. В этом случае ограничение накладывается системой.
Можно узнать ограничение системы для текущего пользователя с помощью команды:

ulimit -a

А для всей системы в целом:

sysctl fs.file-max

Установить же новое значение для ограничения по файлам для текущего пользователя можно так:

ulimit -n значение

Если новые ограничения устанавливаются пользователем root и им же перезапускается Ваша программа, то, несмотря на то, что программа работает от имени другого пользователя, у неё должны вступить в силу новые настройки. Перезапустив программу, можно проверить, применились ли новые значения. Например, выполнить в MySQL команду:

show variables like ‘open_files_limit';

Однако, новые значения ограничений, устанавливаемые утилитой ulimit действуют в рамках одной сессии. Это означает, что при следующем подключении, настройки ограничений системы вернуться к исходным. Чтобы не использовать каждый раз данную утилиту, можно задать параметры ограничений в файле /etc/security/limits.conf. Например, для снятия ограничения на количество одновременно открытых файлов (до 65к, чего хватает в большинстве случаев) для всех пользователей, добавить в конец файла строки:

* soft nofile 65536
* hard nofile 65536

Также следует знать, что файл limits.conf является конфигурационным файлом PAM. А далеко не все программы при запуске используют PAM. Если Ваша программа из числа тех, что не используют PAM, то перед правкой файла limits.conf следует проверить директорию /etc/default/ на наличие конфигурационных файлов Вашей программы. И, если таковые имеются, добавить в конец её конфигурационного файла команду «ulimit -n 65536». Если же в /etc/default/ конфигурационных файлов Вашей программы нет, то можно принудить использовать настройки limits.conf для всех, добавив в конец файлов /etc/pam.d/common-session и /etc/pam.d/common-session-noninteractive (при наличии оного) строку:

session required pam_limits.so

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