Як скопіювати права доступу acl при перенесенні даних з сервера на сервер - системне

Виникла необхідність перенести файли з однієї мережевої кулі на Лінуксі на інший сервер. Обидва сервера включені в домен AD. Здавалося б просте завдання, бери та копіюй. Права доступу повинні зберегтися, адже обидві машини в одному і той же домені. Але все виявилося не так просто.

Для мене було великим здивуванням, що при простому копіюванні через windows машину права доступу не зберігались. На обох серверах була файлова система з підтримкою ACL. Встановити потім права вручну можна було. Тобто функціонал весь був, але права доступу не зберігались. Зазначу відразу, що сервер, з якого забирав інформацію був QNAP, копіював на CentOS 7.

Другим етапом була спроба примонтировать відразу на сервер приймач файлову кулі через cifs. Але при цьому права доступу ACL теж не копіювалися. Став шукати інформацію на цю тему в інтернеті і знайшов, що дійсно, через cifs acl права не переносяться. Там є свої утиліти для перевірки і призначення прав: getcifsacl і setcifsacl. Вручну колупатися з цим не захотілося.

Як скопіювати права доступу acl при перенесенні даних з сервера на сервер - системне

Я міцно задумався, як же бути. У мене не було часу розбиратися детально, потрібно було швидко щось придумати. Можливо я десь помилився або неуважно дивився і цей процес все ж можна провести швидко. Був би радий раді на цю тему. Раніше мені не доводилося займатися переносом даних з samba куля зі збереженням доступу. А дані з віндовий куля без проблем переносяться зі збереженням прав доступу. Навіть не знав, що можуть виникнути такі проблеми при перенесенні інформації з куля на samba.

В результаті для перенесення даних зі збереженням прав доступу ACL я поступив таким чином. На першому сервері, де лежали дані виконав команду:

Команда рекурсивно зібрала права доступу з усіх каталогів і файлів і записала в текстовий файл. Якщо кулі дуже велика, то файл буде значних розмірів. У мене на кулі з 80 000 каталогів і 500 000 файлів такий файл займав 240мб. Далі було б здорово зробити на сервері приймачі команду:

І на цьому закінчити. Але все не так просто. По-перше, в отриманому файлі були вказані шляхи в наступному форматі:

За допомогою цієї команди я замінив фразу share / MD1_DATA на / shares і отримав тепер правильний шлях / shares / soft / Player.

Але це було не все. Далі в файлі з правами доступу зустрічалися доменні користувачі, а локальні того сервера, з якого переїжджали. Потрібно було їх теж всіх видалити, інакше команда не відпрацьовувала, вилітала з помилкою. У моєму випадку це були учасники: admin, guest, everyone. Я знову ж за допомогою sed просто видалив всі рядки, де зустрічалися ці фрази. Робив це про всяк випадок поетапно з перевіркою на кожному етапі. Вийшло ось так:

Можна було все в одній команді зробити, але я не дуже сильний в побудові регулярних виразів, не було часу розбиратися, зробив так. Утиліта на подив швидко працює. Буквально 2-3 секунди і рядки видалені з файлу.

Після цього на сервері приймачі запустив команду:

І все доменні права доступу благополучно встановилися. Утиліта працювала досить довго, хвилин 15.

Сподіваюся, мій досвід здасться комусь корисним. А ще краще, якби мені хтось підказав, як ту ж саму операцію зробити простіше і швидше. Я чомусь переконаний, що є простіший спосіб. Можливо проблеми були через те, що один з серверів був QNAP. По ідеї це лінукс, є доступ по ssh, всередині samba. Але як там все докладно влаштовано не знаю, можливо щось змінено.

Вітаю!
Минулого разу, коли у мене була задача перенесення даних з сервера на сервер, зі збереженням прав, я як і ви мутіл скрипти з getfacl і setfacl. І також як і ви розумів що повинен був бути спосіб краще.
Сьогодні я згадав про rsync. Налаштував між серверами доступ по ключам і скопіював каталог з старого сервера на новий ось так:
# / Usr / bin / rsync -e 'ssh -l root -i /root/.ssh/id_rsa' -progress -lzuogthvrpA -compress-level = 9 -delete-after root @ oldserver: /share/Profiles/user.V2 / share / Profiles /

Власне за збереження ACL прав відповідає ключик -A

Але ж на різних серверах локальні uid будуть різні у одного і того ж доменного користувача, якщо настройки winbind розрізняються. У такому випадку цей варіант не пройде.