Permission denied

1. Файл у тебя локальный, а права ты на удалённом сервере по ssh правишь.
2. Оно cannot create, а не rewrite, прав нет на каталог /etc/default, чтоб создать в нём файл.
3. Если файл нужен не на локалхосте, а на том сервере, к которому ты по ssh подключаешься, man ssh. Ну и man bash, наверное…
4. https://www.linux.org.ru/help/markdown.md

В данном случае файл пытаюсь создать на этом же сервере, где нахожусь. Пробовал и не под SSH , та же ошибка. Я правильно понял, что нужно дать права на директорию одним уровнем выше?

В данном случае файл пытаюсь создать на этом же сервере, где нахожусь.

Тогда зачем ssh?

Просто echo 'ETCD_ADVERTISE_CLIENT_URLS="http://xx.xx.xxx.xxx:2379, http://localhost:2379"' >> /etc/default/etcd.

От какого юзера команда запускается? Вот ему дай права на /etc/default, если нужного файла там пока нет. Если есть — можно только на сам файл.

Ну или от рута делай.

Всё же на всякй случай ещё лишний раз уточню: Ты точно уверен, что тебе файл именно на локалхосте нужен, а не на том сервере, на котором ты команды эти исполняешь с помощью ssh? Просто нафига тут вообще ssh тогда…

Я всё же подключу libastral.so и предположу, что файл тебе нужен таки на этом xx.xx.xxx.xxx, а вовсе не на локалхосте. Иначе это всё просто не имеет смысла.

Тогда, собственно:

ssh root@xx.xx.xxx.xxx 'echo ETCD_ADVERTISE_CLIENT_URLS=\"http://xx.xx.xxx.xxx:2379, http://localhost:2379\" >> /etc/default/etcd'

А то ты запускаешь на локалхосте команду ssh, а её вывод перенаправляешь в файл. Удалённый сервер об этом самом перенаправлении вывода твоего не знает ровным счётом ничего.

На сервере, SSH ввожу по привычке, потому что параллельно делаю команды на неск других серверах через ssh. Запускаю от рута.

Сделал вот так: chown root:root /etc/default

chmod 644 /etc/default , все равно та же ошибка permission denied

Это каталог, поэтому надо 755 уж тогда.

И покажи конкретные команды, которые ты вводил.

SSH ввожу по привычке, потому что параллельно делаю команды на неск других серверах через ssh

Не надо так.

Короче, чтоб наверняка:

mkdir -p /etc/default
chmod 755 /etc/default
chmod 644 /etc/default/etcd
echo 'ETCD_ADVERTISE_CLIENT_URLS="http://xx.xx.xxx.xxx:2379, http://localhost:2379"' >> /etc/default/etcd

И без всяких ssh, не надо усложнять. Запускать echo на удалённом сервере, чтобы записать при этом этом в локальный файл — это маразм какой-то.

Это чтоб наверняка сработало, потому что нифига не понятно, есть ли у тебя этот каталог вообще, есть ли в нём этот файл…

mkdir -p /etc/default
...
chmod 644 /etc/default/etcd

Может все-таки mkdir -p /etc/default/etcd ?

Ни в коем случае. Тогда точно в этот файл ничего не удастся записать. Потому что с этим именем будет каталог.

Понял, вроде бы получилось. Я понимаю что в данном случае SSH не нужен, учитывая что я на это же сервере создаю. Но я все равно не понял почему через ssh root@xx.xx.xxx.xxx echo ‘ETCD_ADVERTISE_CLIENT_URLS="http://xx.xx.xxx.xxx:2379, http://localhost:2379"’ >> /etc/default/etcd так и осталось permission denied,

А если я захожу просто под sudo -i И делаю echo ‘ETCD_ADVERTISE_CLIENT_URLS=«http://xx.xx.xxx.xxx:2379, http://localhost:2379»’ >> /etc/default/etcd То так работает.

Понимаю что возможно вопрос глупый , но все же)

Осиль https://www.linux.org.ru/help/markdown.md !

Ты вот это ssh root@xx.xx.xxx.xxx echo 'ETCD_ADVERTISE_CLIENT_URLS="http://xx.xx.xxx.xxx:2379, http://localhost:2379"' >> /etc/default/etcd ГДЕ запускаешь? На той же машине, где /etc/default/etcd рассчитываешь получить? Или таки удалённо?

На этой же

Ни в коем случае. Тогда точно в этот файл ничего не удастся записать. Потому что с этим именем будет каталог.

В глаза долблюсь :(((
2ТС мой коммент Permission denied (комментарий) считать заведомо ложной информацией и провакацией!

Тогда это:

А если я захожу просто под sudo -i

Ну так ssh-то ты не из под root’а запускаешь, видимо? Ежели у тебя «если sudo -i» идёт как другая ветка, то видимо, от другого. Ну так вот поэтому и нет прав — у рута есть (после sudo -i), у юзера, от которого ты этот ssh запускаешь, нет.

Ну и в любом случае, не надо так делать, это маразм какой-то. Зачем использовать ssh просто чтобы что-то вывести…

Вот так сработает в этом случае:

ssh root@xx.xx.xxx.xxx echo 'ETCD_ADVERTISE_CLIENT_URLS="http://xx.xx.xxx.xxx:2379, http://localhost:2379"' | sudo tee -a /etc/default/etcd

Но ещё раз — не надо так делать, это маразм. Зачем подключаться к локалхосту по ssh, чтобы потом записать на нём результат в файл, но уже без всякого ssh, при том, что по ssh запускается ничто иное как просто echo… Это просто идиотизм, поэтому я столько раз и переспрашиваю, та же ли эта машина — ибо выглядит будто нет.

Ну или уж тогда так:

ssh root@xx.xx.xxx.xxx 'echo ETCD_ADVERTISE_CLIENT_URLS=\"http://xx.xx.xxx.xxx:2379, http://localhost:2379\" >> /etc/default/etcd'

Тоже сработает, потому что вся команда и запись в файл тоже будет запущена от рута по ssh. А не echo по ssh, а перенаправление вывода нет.

И вот в этом уже есть смысл, потому что в таком виде это имеет смысл и удалённо, а не только если xx.xx.xxx.xxx это локалхост.

Замени путь на /tmp/etcd

Ты конечно всё правильно написал, но если б я был нубом - наверно понял бы только четвёртый пункт. И дальше тоже даёшь готовые команды без внятных объяснений что именно ты в них исправил и почему - он так не научится нормально.

Я пытался:

А то ты запускаешь на локалхосте команду ssh, а её вывод перенаправляешь в файл. Удалённый сервер об этом самом перенаправлении вывода твоего не знает ровным счётом ничего.

Но дальше он говорит, что он с локалхоста на локалхост же и делает ssh — непонятно зачем.

Соответственно я вполне объясняю, в чём дело и дальше:

Ну так ssh-то ты не из под root’а запускаешь, видимо? Ежели у тебя «если sudo -i» идёт как другая ветка, то видимо, от другого. Ну так вот поэтому и нет прав — у рута есть (после sudo -i), у юзера, от которого ты этот ssh запускаешь, нет.

(тут, конечно, стоит добавить, что важно не от какого юзера запущен именно ssh, а от какого юзера вся команда исполняется, и конкретно >> шелловское интерпретируется, но я хотел добавить это после ответов, рут это таки или нет)

Ну и далее тоже с объяснением:

Тоже сработает, потому что вся команда и запись в файл тоже будет запущена от рута по ssh. А не echo по ssh, а перенаправление вывода нет.

Это не голые команды без пояснений. Не спорю, можно объяснить и лучше наверное. Но тут уж давай тогда сам класс показывай ;)

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

---------------------------------------------------------------

Если ты пишешь что-то типа такого

ssh username@host command >> /some/file

1) команда для запуска - ssh

2) её аргументы - username@host и command (они передаются ssh-у и работает с ними исключительно он)

3) файл куда записать результат команды (то есть, внимание, результат работы ssh) - /some/file

При этом все эти действия (и запуск ssh и запись в файл) будут производиться от текущего пользователя (судя по символу $ который у тебя виден это не рут). То, что у тебя указано username@host - это, ещё раз, аргумент для ssh, который указывает куда подключаться. Но файл /some/file создаётся не ssh-ем и не на удалённом указанном хосте, а шеллом (bash?) в который ты ввёл эту команду. Весьма частая ошибка считать что «>> /some/file» отправится аргументом в команду (т.е. в данном случае в ssh). Если тебе действительно надо чтобы «>> /some/file» было частью команды, отправляемой в ssh, надо заключить в кавычки, вот так:

ssh root@xx.xx.xxx.xxx 'echo \'ETCD_ADVERTISE_CLIENT_URLS="http://xx.xx.xxx.xxx:2379, http://localhost:2379"\' >> /etc/default/etcd'

В таком виде команда будет рассматриваться так:

1) команда для запуска - ssh

2) её первый аргумент - root@xx.xx.xxx.xxx

3) её второй аргумент - echo 'ETCD_ADVERTISE_CLIENT_URLS="http://xx.xx.xxx.xxx:2379, http://localhost:2379"' >> /etc/default/etcd (благодаря кавычкам он передаётся как одно целое, и, обрати внимание, одинарные кавыки внутри самого аргумента надо было предварить обратными слэшами (\') чтобы показать что это не закрывающая кавычка второго аргумента ssh, а символ внутри него.

Таким образом, ssh запустится, подключится к руту на указанном хосте, и выполнит на нём команду echo с записью в файл. Сам ssh, как и раньше, будет запущен от не-рута, но действия, которые он отправляет на ту сторону, делаются уже рутом (включая запись файла на той стороне).

---------------------------------------------------------------

Вторая проблема. Ты считаешь, что с помощью chown root:root можно выдать кому-то какие-то права. Это не так. У рута и так есть права на всё, вне зависимости от того какой владелец и группа у файлов, а так же вне зависимости от того какой там chmod. То есть chown root:root может выполнить только одну функцию: удостовериться, что у не-рута прав тут не будет. У рута же они есть в любом случае.

Собственно, если руту пишет permission denied, то проблема точно не в правах на файлы. Скорее всего (как у тебя) ты просто перепутал рута с не-рутом. В других редких случаях это действительно может быть что-то с правами, но точно не с теми которые chown/chmod (ты скорее всего с этим не столкнёшься).