за что я не люблю *nix world

[brmail]

 Вот стоит в кладовке Synology NAS, жужжит тихонько, стиль работы - настроил и забыл, годами можно не трогать. Всего две компоненты - комп, который реализует доступ к набору HDD, Raid-массивам итд. И спец-оболочка, предназначенная работать GUI для удобства пользования. Еще для удобства пользования можно поставить толпу пакетов с разной функциональностью, от бекапов до медиа-плеера. 
Но основное предназначение оболочки  - NAS, управление файловой системой и тд, все в GUI. 
Ну вот, добавил я в боксик новый драйв, теперь у меня не один том, а два, и появилось желание сделать несколько hardlinks (or symbolic links) для отображения одних фолдеров внутри других без их физического объединения.  
В той самой винде это делается прямо из кнопки старт - пускаем cmd  и печатаем строку-команду какой фолдер мапить куда. 
Причем для особо ленивых, можно скачать бесплатную утилиту, которая то же самое сделает через GUI 
В синолодже прямо не отходя от кассы (ui) есть пару способов смонтировать remote folder, есть даже специальный менаджер для управления ремот фолдерами. Но с дисками внутри одного бокса оно не работает. Хочет чтобы был полный ip удаленной системы, куда он будет коннектится. Подсовывание собственного ip - не удовлетворяет, непонятно почему.
А для создания symbolic links я должен где то настройках бокса разрешить телнет, скачать и поставить этот телнет клиент, пойти напечатать команду... и оно работать не будет, потому что нужно в каком то неявном месте подкрутить permissions.
Причем, примерно в 2018 разработчики обещали прикрутить эту опцию в  UI, но воз и ныне там - ведь есть же команда в телнете, к чему дергаться?

ЗЫ Да начнется срач!

Comments

[brmail]

Оно, оно. Там же где включается телнет. Те сперва должно его включить. После чего можешь смело фигачить туда все команды, что нашел в интернете, с немалым шансом уронить все по незнанию, особенно это касается ситуации, когда играешся не с правами куда-то в фолдеры, а с дисковой структурой.
Те вместо безопасного и удобного инструмента я получаю доступ к гранате и обезьяне которая эту гранату обязательно рванет. А когда рванет в интернете обязательно ответят: "так ты ламер, куда ты нафиг грязными руками полез".
Не, я не спорю, любые знания могут пригодится, и что угодно можно сперва изучить, а потом уже лезть. Но ради маппинга фолдера с одного диска в фолдер другого... ? Оно мне нада?

[cybernatic_cat]

Те сперва должно его включить.

Разумеется. Ибо консольный доступ - вещь сильно небезопасная. Она даже в native *nix продакшен системах, обслуживаемых квалифицированными юниксоидами, ограничена строжайшим образом. И уж тем более - она должна быть по дефолту выключена в customer-grade appliances.

После чего можешь смело фигачить туда все команды, что нашел в интернете, с немалым шансом уронить все по незнанию

Вот-вот, именно поэтому :).

Но ради маппинга фолдера с одного диска в фолдер другого... ?

Судя по всему, создатели этого appliance такой use case просто вообще не рассматривали. Пепяка твоя рассчитана на логику "есть один драйв в коробке - маппим его виндовому клиенту как диск X (строго говоря, функции NAS здесь ваще ни при чём, это работа клиентской стороны); воткнули второй диск - замаппили как Y". И я не очень понимаю, почему бы твой юзкейс не реализовать также на стороне клиента, алгоритмом вроде следующего:

1. Маппим первый физический винт как X.
2. На втором создаём папку "Porno2" и маппим его как Y.
3. Запускаем на клиенте команду mklink /D Porno2 Y:\Porno2

Насколько я ничего не помню о винде - должно сработать.

[brmail]

должно, только тогда это надо над каждым клиентом так издеваться. А хотелось иметь решение сразу на стороне сервера.

[cybernatic_cat]

Ну тогда копайся в физической файловой системе :). Тот самый ln -s. Хотя, повторюсь, я бы сначала посмотрел, нету ли в синолоджи lvm, и если есть - действовал бы через туда, хотя это и сложнее (зато правильнее). Хотя вот здесь пишут, что там ваще смесь бульдога с носорогом, тоись btrfs и lvm, и я бы не рекомендовал с таким играться без соответствующего экспириенса...

Впрочем, нужно заметить, что монтаж SMB/CIFS-shared папок в пределах одного сервера (тоись, "монтаж на самом себе") теоретически возможен. Но для этого должен соблюдаться ряд условий:
1. Сервисы smbd и nmbd должны отвечать на адресах из локальной подсети 127/8 (что далеко не всегда так).
2. На сервере должен быть установлен пакет cifs-utils (что, опять же...)
3. Монтируемые папки должны иметь правильные атрибуты доступа.

Как видишь, не сильно просто даже в варианте без гуя :). Думаю, потому создатели и не заморачивались.

[brmail]

Ну в принципе я нашел в просторах интернета видео-гайд на 10 минут куда и как нажимать и что печатать для именно того что надо мне. Подразумевает именно ssh, на мне не в падлу его разрешить а потом запретить. Создается symbolic link, что никак не выглядит опасным для того куда оно создается, если там пустой фолдер.

что то типа :

ssh admin@
mkdir /volume2/share/music
sudo mount --bind /volume1/music /volume2/share/music

ну и для того чтобы сделать этот линк постоянным надо
sudo vi /etc/rc.local
sudo mount --bind /volume1/music /volume2/share/music

не очень понятно нельзя ли сразу:

mkdir /volume2/share/music
sudo vi /etc/rc.local
sudo mount --bind /volume1/music /volume2/share/music

ну и неплохо бы найти как это дело unmount, если что.
Еще в интернете пишут про несоотвествие прав, которые возможно придется фиксить.

[cybernatic_cat]

Это не совсем симлинк - точнее, совсем не симлинк, это вторичное монтирование раздела - но работать будет :). Учти только, что если /volume1/music внутри себя содержит, в свою очередь, ещё какие-то точки монтирования (тоись, иерархию монтирования) - то такая иерархия вторично смотирована не будет. Тебе вряд ли это понадобится, но если что - для такого нужен ключ --rbind вместо --bind.

не очень понятно нельзя ли сразу:

mkdir /volume2/share/music
sudo vi /etc/rc.local
sudo mount --bind /volume1/music /volume2/share/music

Можно, конечно. Первая команда - создание директории. Вторая - вызов редактора vi и открытие файла /etc/rc.local на редактирование. /etc/rc.local - это скрипт, который отрабатывается при старте системы, туда нужно внести дополнительную команду "sudo mount --bind /volume1/music /volume2/share/music", тогда вторичное монтирование будет отрабатываться при перезагрузке девайса, так что это просто "задел на будущее", и порядок операций не имеет значения (ну только mkdir должен выполняться первым). А третья - это, собссно, монтаж файловой системы "прямо сейчас".

Кстати, то, что ты написал, не совсем корректно. По пунктам:

mkdir /volume2/share/music - здесь правильно: отдать консольную команду создания директории, в эту директорию будет вторично смонтирована файловая система /volume1/music.

sudo vi /etc/rc.local - на этом месте ты получишь экран редактора vi и текст скрипта rc.local в нём. Никаких операций типа "sudo mount --bind /volume1/music /volume2/share/music" ты в редакторе учинить не сможешь, vi имеет свою систему команд. Они могут разниться в зависимости от типа системы и версии самого vi, но чаще всего будет работать следущее:

- нажать Insert (при этом внизу экрана должна появиться строка "INSERT", если нет - нажать i вместо Insert)
- перегнать курсор в самый низ файла, на новую пустую строку
- впечатать (или загнать из клипборда) вот ту самую команду sudo mount --bind /volume1/music /volume2/share/music
- нажать Esc
- ввести следующую команду: ":wq" (без кавычек) - ":" переводит редактор из режима редактирования в режим воспринятия команд, "w" записывает изменения в файле, "q" инициирует выход из редактора.
- для проверки, что файл изменён правильно, и что все изменения сохранились - отдать консольную команду cat /etc/rc.local, тебе распечатают содержимое скрипта.

И вот потом уже можно в командной строке отдать команду sudo mount --bind /volume1/music /volume2/share/music - это вторично смонтирует файловую систему на лету, не дожидаясь перезагрузки и отработки rc.local.

[brmail]

спасибо, пока я полазил через ssh c ls по каталогам,
выполнил
mkdir
sudo mount --bind
с правильными путями, сработало, вижу созданную директорию, вижу файлики и фолдеры которые там ожидаются.

Вот через пару часов закончися копирование, ребутну бокс и попробую посоветованное с vi чтобы сделать линк постоянным. Ну и незабыть отключить разрешенный телнет/ssh после всего.


ЗЫ К моему удивлению повершелл из windows server 2016 нефига не знает про ssh, тогда как тот же повершелл из windows 10 pro прекрасно о нем знает.

[cybernatic_cat]

ребутну бокс и попробую посоветованное с vi

Если ты ребутнёшь бокс, не выполнив предварительно операций в vi - после ребута ты потеряешь вторичный монтаж. /volume2/share/music будет выглядеть пустой. Повторная команда sudo mount --bind
> /volume1/music /volume2/share/music восстановит всё как было, но всё-таки.

[brmail]

да, я уже занес все куда надо. Жду окончания копирования, чтобы убедиться что все в порядке.

[cybernatic_cat]

Вдогонку: приведенной тобой рецепт - это как раз то, что для не-юниксоида совершенно не очевидно, это та самая парадигма юниксов "нету ваще никаких дисков C, D etc, есть только файловые системы и точки монтирования - и оперируя с ними, можно творить просто невероятные извращения: монтировать один и тот же раздел дважды в разные места, менять пути, по которому следует обращаться к файловой системе и т.д." С точки зрения человека, привыкшего к винде, решение с симлинками (ln -s) куда ближе и очевиднее, посколько это прямой аналог junctions в винде. К тому же, при работе с симлинками куда меньше вероятность наступить на ошибки с правами доступа, поскольку к симлинкам права неприменимы, при обращении к ним всегда рассматриваются только права того каталога/файла (кстати, в юниксах это одно и то же :)), на который указывает линк. А вот при вторичном монтаже - всё может быть весьма сложнее.

[brmail]

следует учитывать, что там не чистый линукс, а что то допиленное напильником.
Я начал читать что пишут, и вот наткнулся на:
Maybe your first option would be to use the ln command but I’m sorry to say that it will maybe not work properly because the access to symbolic links via Samba/FTP is disabled on the NAS for security reasons and I haven’t found a way to enable it. So the symbolic link might work in some cases, such as using an UPnP client or on the DS audio app, but not from the DS file app or on File Station.

Ну а мне как бы хотелось безусловного линка туда куда я хочу, после просто положу рядом с фолдером ридми файл, чтобы позже ручки не потянулись удалить непонятные "дубли", мало ли что через годы будет в голове.

[cybernatic_cat]

следует учитывать, что там не чистый линукс, а что то допиленное напильником

Без разницы. Основые принципы у всех юниксов одинаковые, это posix. Самое смешное в том, что в основе файловых системы винды тоже posix :)). Но вот там - уже перепиленный так, что мама не горюй.

it will maybe not work properly because the access to symbolic links via Samba/FTP is disabled on the NAS for security reasons

Да, такое вполне возможно, и я этого не учёл. Это тоже лечится, установкой параметра "allow insecure wide links = no" в /etc/samba/samba.conf и перезапуском демонов smbd и nmbd (ну или рестартом всей системы) - но это таки может быть дырой в безопасности. Не сильно критичной для домашнего NAS, но вроде бы по умолчанию оно закрыто в поставке Samba.

[brmail]

В любом случае спасибо, файла rc.local не было, vi его с твоей помощью создал.
Если все будет работать после рестарта - ничего переделывать я не буду, все прекрасно и так.

[cybernatic_cat]

Если не заработает после рестарта - пиши, попробую помочь. Разные flavors юниксов имеют разные механизмы запуска скриптов при старте системы, и rc.local есть далеко не во всех (более того, в некоторых он не отрабатывается, даже если его создать).

[brmail]

Да, все на месте. Спасибо за советы.

[brmail]

Ничего не длится вечно - диск начал покрываться бед секторами. Что будет, если я его выну из бокса и рестартну сам бокс?
rc.local сейчас содержит ссылку на диск, которого при рестарте уже не будет. Все навернется или просто исчезнет маппинг и фолдер, в который этот маппинг сделан просто будет пустой?

Ну, те я, вероятно, могу еще раз отредактировать и убрать оттуда sudo mount --bind /volume1/music /volume2/share/music
Но я планирую поставить вместо того диска новый. По сути мне важно, чтобы система не рухнула, пока я буду всем этим заниматься.

[cybernatic_cat]

rc.local сейчас содержит ссылку на диск, которого при рестарте уже не будет. Все навернется или просто исчезнет маппинг и фолдер, в который этот маппинг сделан просто будет пустой?

Скорее всего, при старте системы ядро ругнётся на то, что не может смонтировать раздел - и перейдёт в консоль однопользовательского режима, запросив рутовый пароль. Там ты сможешь, при желании, вызвать текстовый редактор (тот же vi), отредактировать rc.local, закомментировав там дохлый монтаж, и продолжить загрузку (ну или ребутнуть ещё раз). Но лучше действительно сделать это заранее, до ребута и даже до вытаскивания диска из бокса :).

[brmail]

Ага, спасибо.
Видимо самым простым решением будет после захода в ssh дать команду rm /etc/rc.local чтобы точно ничего не напортить с редактированием.
И со спокойной душой рестартнуть бокс.
После чего вытаскивать из него диск. Доводить систему до вылета в консоль, чтобы потом пытаться решать проблемы с доступом к ней (монитора и клавы там же нет) мне явно не хочется.
А потом, когда там будет новый драйв у меня уже есть инструкция, как сделать новый rc.local и что туда писать.

[brmail]

разрешил ssh, активировал админ аккаунт из состояния disabled
зашел с этим аккаунтом

admin@SYN:~$ mv /etc/rc.local /etc/rc.old
mv: cannot move ‘/etc/rc.local’ to ‘/etc/rc.old’: Permission denied

admin@SYN:~$ rm /etc/rc.local
rm: remove write-protected regular file ‘/etc/rc.local’? Yes
rm: cannot remove ‘/etc/rc.local’: Permission denied

Те явно у него не хватает пермишенс удалять или переименовывать. Это default admin синолоджи боксика. Где бы его попинать?

ЗЫ Загрузил файл в vi - удалил в нем строку. нажал :wq ентер, все без вопросов сохранилось. Ну прикольно же, удалять - фигу, переименовать - тоже фигу, зато редактировать - ради бога.
проверил cat /etc/rc.local
выдает пустую строку, те отредактировать оно мне его дало.
Пустой скрипт rc.local не должен вызывать никаких проблем с загрузкой системы?

PS2: sudo rm /etc/rc.local файл удалило
ТАк что считаем что проблема решена

[cybernatic_cat]

Подсказку "$" в командной строке видишь? В линуксах (и во многих *nix) она, по умолчанию, обозначает, что текущий пользователь - regular. А не root. У рута подсказка другая: "#". А подавляющее большинство конфигурационных файлов в /etc - для записи (и, соответственно, для удаления-перемещения) доступно только руту.

А вот почему тебе таки позволили редактировать rc.local, но не позволили его удалить либо переместить... Тут у меня идей очень немного, вообще говоря :). В принципе, во многих файловых системах linux есть расширенные атрибуты доступа, и некоторые из них вполне позволяют исполнять именно такие трюки: типа, файл можно редактировать, но нельзя удалить. Если ты отдашь команду "lsattr /etc/rc.local" и кинешь результаты сюда - то я смогу сказать точнее, но навскидку похоже именно на это. И, заодно, посмотри, что отвечает команда "ls -la /etc/rc.local".

Пустой rc.local, по идее, должен прокатить. Теоретически, это банальный скрипт, а для пустых скриптов принято просто писать "exit 0" сразу после указания командного интерпретатора - но rc.X в линуксах есть особый случай (более того, практика rc.X сильно устарела, в современных линуксах оставлена только для обратной совместимости) - поэтому можно оставить файл скрипта пустым.

[brmail]

ДА, спасибо.
sudo rm файл удалило. Перегрузил бокскик не вынимая старого диска - фолдер куда был маппинг сейчас пустой, значит все прошло как надо. Потом просто повторю шаги что у меня выше записаны. Сейчас все вернул как было - ssh запретил, админский аккаунт заблокировал. Буду возвращать как было - заодно проверю что пишут на твои команды.

[brmail]

Довольно много у меня заняло время все это пересобрать обратно.
Вот, смонтировал заново все, и заодно запустил две команды из твоего коммента:

admin@SYN:~$ lsattr /etc/rc.local
-------------e-- /etc/rc.local

И вторая:

admin@SYN:~$ ls -la /etc/rc.local
-rw-r--r-- 1 root root 80 Jan 14 04:59 /etc/rc.local