Faheem корректен; общая опция группы решила бы Вашу проблему, предположив, что я правильно понимаю Вашу проблему.
Можно использовать эту команду для нахождения самого высокого, в настоящее время присваиваемого GID в каждой системе (uniq не необходим, но не включен из привычки):
awk -F':' '{ print $3 }' /etc/group | sort -n | uniq | tail -1
Обратите внимание на то, что, безотносительно вывода этой команды, могут также быть перекрытия в неиспользованном GID в нижнем значении, однако, выбирание GID выше печатного значения гарантирует, что никакая система уже не использует идентификатор.
Любой набор полномочий группы на рассматриваемой папке (папках) будет затем относиться ко всем членам группы в обеих системах.
Также обратите внимание, что названия группы не должны соответствовать, хотя для Вашей собственной исправности это может быть желательно.
Чтобы добавить одного или несколько пользователей к группе, в зависимости от Вашего дистрибутива Linux, у Вас может быть доступ к команде gpasswd:
gpasswd -a <user> <group/GID>
Испытывая недостаток в этой утилите, или предпочтением, можно внести то же изменение путем выполнения:
usermod -G $(groups <user> | sed 's/ /,/g'),<new group> <user>
Обратите внимание на то, что эта команда предполагает, что Вы требуете установить дополнительную группу, а не основную группу для указанного пользователя.
Это обычно зависело бы от Вашей операционной системы, типа компьютера, который Вы используете, и насколько резкий перезагрузка была.
Много подобных Unix операционных систем (включая популярные основанные на Linux) удерживают свои журналы /var/log
. На некоторых других, /var/adm
стандартное местоположение. Определенные файлы, хранившие там, зависят от ОС, распределения и конфигурации. Искать kernel
или kernel.log
, затем попробуйте messages{,.log}
или syslog{,.log}
.
Некоторые Нельды не-Linux могут представить полный отчет катастрофического отказа каждый раз, когда это происходит. Проверьте документы ОС, где дамп катастрофического отказа хранится, и как считать его.
Если Ваш компьютер имеет плату управления сервером, плату IPMI или somesuch, причина перезагрузки может быть зарегистрирована там. Проверьте журналы через веб-интерфейс или ipmitool
. Если Ваша системная плата имеет более немой сторожевой таймер, сторожевой таймер может быть ответственен за перезагрузку, но это не будет зарегистрировано.
Если Вы все еще не можете найти информацию, существует два случая: любой перезагрузка является слишком внезапной, чтобы журналы были записаны (рассматривают монтирование Вашего /var
раздел sync
временно — это - серьезный пожиратель ресурсов производительности), или нет никаких журналов, которые будут записаны. В последнем случае проблемой является или аппаратный отказ очень низкого уровня или проблема источника питания (например, сигнал POWEROK от de-утверждения источника питания и порождения аппаратного сброса или полумертвого аккумулятора для ноутбука, ведущего себя странно — ноутбук, я иду прямо сейчас, как было известно, иногда делал это при работе заряда батареи).
/var/log/kern.log.*
,/var/log/syslog.*
. Я попытаюсь изучить их.Спасибо. – sawa 27.05.2012, 18:33