Не может изменить или показанные файлы на readynas доле nfs
Насколько я понимаю нагрузка на *отклоняет системные средства "количество процессов, ожидающих для выполнения". Это не обязательно означает, что они ожидают ЦП. Они могли ожидать доступа к диску, или сетевого соединения для завершения.
Например, я раньше управлял системой, где загрузка начала запускать более чем 80 иногда обеспечения системы к проверке. Это закончило тем, что было, потому что внешний сервер LDAP неправильно функционировал, против которого локальная система делала запросы аутентификации для клиентов.
Я искал бы сетевые зависимости, которые Ваши приложения имеют как возможный преступник для необычно высоких чтений загрузки, если Ваш ЦП и iowait кажутся OK.
Это вполне, конечно, связано с root_squash'ing.
Я предполагаю, что Вы уже читали о root_squash, но для полноты..
Когда в действительности это повторно отображает привилегированный UID и GID 0 к тому из 65534 который обычно является пользователем nobody. Итак, если root должны были создать файл на раздавленной доле, которой он будет принадлежать nobody. Это вызывает некоторое преимущество безопасности - хотя возможно не много, как root пользователь на клиенте NFS мог явиться олицетворением любого другого UID вместо этого.
В ответ на Вашу проблему действительно ли Вы уверены, что вторая группа экспорта используется? Доля была реэкспортирована начиная с измененных опций? Сервер NFS, который в состоянии правильно разрешить имя хоста mattr-desktop?
Если ответ на все них - "да", то это нечетно. Можно хотеть попробовать опции anonuid=0,anongid=0 просто для разрешения полномочий на том файле.
exportfs -raдолжен был сделать то же задание. – Dan Carley 26 November 2009 в 11:00