CP Ubuntu-p на смонтированном пуле ZFS

Я предполагаю, что Ваш статический IP продолжает работать отлично, но установка DHCP на другом NIC заставляет его становиться шлюзом по умолчанию, как проинструктировано сервером DHCP.

Для тестирования этой небольшой теории работать route когда только связанный со статическим NIC при соединении только с локальной LAN, и при соединении с обоими.

Необходимо видеть, производит что-то как:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.39.0    *               255.255.255.0   U     0      0        0 eth0
default         192.168.39.1    0.0.0.0         UG    0      0        0 eth0

Вы будете видеть больше строк при соединении через большее количество NICs, и больше если у Вас есть какая-либо дополнительная настроенная сетевая маршрутизация (такая как VPNs). Важная строка является той, отмеченной как default в destination.

Править: с новой информацией добавил к Вашему вопросу, я не совсем уверен, поскольку я не видел, что расположение (знаю немного при маршрутизации, но я не экспорт!). Похоже, что существует два определенные шлюза, один для каждого сетевого интерфейса. Это может означать, что нет никакого установленного маршрута для пакетов к общедоступным адресам, и это оставляет две потенциальных проблемы: если локальная LAN не будет настроена, чтобы позволить пакетам от Вас быть переданными общедоступным адресам затем, то они не выйдут, и если Вы используете серверы DNS, которые только доступны вниз, одна из строк и другой строки используется, Вы не получите определения имен. Вы могли добавить вывод nslookup example.com и cat /etc/resolve.conf к Вашей информации, и я смог диагностировать далее и предлагать фиксацию.

5
задан 23 August 2010 в 06:36
2 ответа

Решение: Отключите фальсификацию ACL

Это из-за дополнительных полномочий ACL

See & Upvote: https://superuser.com/questions/198758/what-does-the-mean-in-the-acl-output-of-ls-l

Вы получаете "полномочия сохранения для некоторых: Операция, не поддерживаемая", когда Вы cp -p от NFS монтируют, что это имеет дополнительный ACL (ls -l шоу +) к чему-то как/tmp, который не поддерживает дополнительные полномочия.

Для фиксации этого, сначала необходимо заставить сервер NFS прекратить добавлять дополнительные полномочия к новым файлам. На поле OpenSolaris или OpenIndiana ZFS можно сделать это как это:

zfs get sharenfs myzpool1
zfs set sharenfs=XXX myzool1

но вместо XXX помещает то, что Вы имели прежде, и добавьте", noaclfab" (см. man share_nfs)

Можно также удалить эти дополнительные ACLs для существующих файлов:

apt-get install acl
setfacl -b test.sh

Рекурсивно:

find . -exec setfacl -b {} \;

Для закрепления этого на стороне клиента можно обновить эти строки в/etc/sysconfig/autofs:

APPEND_OPTIONS="yes"
OPTIONS="--global-options nosuid,noacl,vers=3,retry=5000”

"noacl" ключевое слово является соответствующей частью, другие опции, вероятно, не требуются работать вокруг этого конкретного вопроса, но они - вещи рассмотреть.

6
ответ дан 3 December 2019 в 01:22

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

Нижняя строка - то, что, если это сохраняет атрибуты, Вы интересуетесь, затем не волнуйтесь.

2
ответ дан 3 December 2019 в 01:22
  • 1
    Аплодисменты для ответа. К сожалению, хотя эта команда выполняется в рамках большого сценария копии, таким образом, она массово рассылает пользователей с сотнями этих ошибок. Какие-либо идеи, как я обхожу это? –  JT.WK 24 August 2010 в 03:42

Теги

Похожие вопросы