Ошибка при копировании (!)
Модератор: SLEDopit
-
Zloydog
- Сообщения: 17
- ОС: Linux Debian
Ошибка при копировании
Ситуация такая — подключился со шлюза на котором стоит Debian к самбе с помощью Midnight Commander через Shell. Стал перекидывать архивы бекапов и Midnight Commander выдает ошибки «Не возможно сменить владельца целевого файла. Ошибка удаленного вводавывода 121» и потом вторая «Невозможно сменить режим доступа целевого файла»
Сходил до сервера воткнул флешку, примонтировал и все спокойно перекинул. Но хотелось бы разобраться в чем проблема данная.
-
drBatty
- Сообщения: 8735
- Статус: GPG ID: 4DFBD1D6 дом горит, козёл не видит…
- ОС: Slackware-current
-
Контактная информация:
Re: Ошибка при копировании
Сообщение
drBatty » 12.11.2014 09:31
Zloydog писал(а): ↑
11.11.2014 17:32
Ситуация такая — подключился со шлюза на котором стоит Debian к самбе с помощью Midnight Commander через Shell. Стал перекидывать архивы бекапов
КУДА копировали?
Zloydog писал(а): ↑
11.11.2014 17:32
Но хотелось бы разобраться в чем проблема данная.
проблема в том, что какие-то атрибуты файлов в удалённой системе не поддерживаются.
Zloydog писал(а): ↑
11.11.2014 17:32
воткнул флешку
это с FAT, да? Так там никакие атрибуты не поддерживаются, только временной штамп, и то 32х битный. Вот вы их все успешно потеряли.
Hint: что-бы не потерять атрибуты(основные, такие как права доступа и владельца), используйте tar-архив для передачи, ну или rsync over ssh тоже хорошо работает.
-
Zloydog
- Сообщения: 17
- ОС: Linux Debian
Re: Ошибка при копировании
Сообщение
Zloydog » 12.11.2014 09:42
drBatty писал(а): ↑
12.11.2014 09:31
Zloydog писал(а): ↑
11.11.2014 17:32
Ситуация такая — подключился со шлюза на котором стоит Debian к самбе с помощью Midnight Commander через Shell. Стал перекидывать архивы бекапов
КУДА копировали?
Zloydog писал(а): ↑
11.11.2014 17:32
Но хотелось бы разобраться в чем проблема данная.
проблема в том, что какие-то атрибуты файлов в удалённой системе не поддерживаются.
Zloydog писал(а): ↑
11.11.2014 17:32
воткнул флешку
это с FAT, да? Так там никакие атрибуты не поддерживаются, только временной штамп, и то 32х битный. Вот вы их все успешно потеряли.
Hint: что-бы не потерять атрибуты(основные, такие как права доступа и владельца), используйте tar-архив для передачи, ну или rsync over ssh тоже хорошо работает.
Копировал с со шлюза (Debian) на Samba файлообменник (debian). Архив создал 1.tar.gz
-
drBatty
- Сообщения: 8735
- Статус: GPG ID: 4DFBD1D6 дом горит, козёл не видит…
- ОС: Slackware-current
- Контактная информация:
Re: Ошибка при копировании
Сообщение
drBatty » 12.11.2014 10:04
Zloydog
очень плохая идея копировать файлы удалённо от/в root-доступ. Это РЕШЕТО.
Так никто не делает, потому и не тестирует никто. А если вы копируете обычным пользователем, то владелец автоматически меняется на получателя. Причём AFAIK в mc всё вроде-бы менялось без ошибок.
Ваша проблема скорее всего в том, что пользователи разные, и mc почему-то хочет сменить владельца файла на отправителя, как оно на локальной системе.
А зачем вы используете именно SMB соединение, ведь оно предназначено лишь для Windows™ систем? Нельзя-ли использовать OpenSSH?
Ещё вопрос: надеюсь вы применяете «SMB соединение», а не «FiSH»?
-
Zloydog
- Сообщения: 17
- ОС: Linux Debian
Re: Ошибка при копировании
Сообщение
Zloydog » 12.11.2014 13:45
drBatty писал(а): ↑
12.11.2014 10:04
Zloydog
очень плохая идея копировать файлы удалённо от/в root-доступ. Это РЕШЕТО.Так никто не делает, потому и не тестирует никто. А если вы копируете обычным пользователем, то владелец автоматически меняется на получателя. Причём AFAIK в mc всё вроде-бы менялось без ошибок.
Ваша проблема скорее всего в том, что пользователи разные, и mc почему-то хочет сменить владельца файла на отправителя, как оно на локальной системе.
А зачем вы используете именно SMB соединение, ведь оно предназначено лишь для Windows™ систем? Нельзя-ли использовать OpenSSH?
Ещё вопрос: надеюсь вы применяете «SMB соединение», а не «FiSH»?
То есть перекидывать из под пользователя? Ну вообще я по SSH и так цепляюсь к серверам..Физически их нет рядом. да smb. Я пробовал менял у архива владельца и группу на те что на папку в которую скидваю тоже не хочет.. мне конечно не лень раз в неделю дойти до сервера подцепить флешку и бекап сделать, но хотелось бы автоматизировать все, чтобы он сам перекидывал бекапы на сервер самбы
-
Bizdelnick
- Модератор
- Сообщения: 20347
- Статус: nulla salus bello
- ОС: Debian GNU/Linux
Re: Ошибка при копировании
Сообщение
Bizdelnick » 12.11.2014 14:30
Zloydog писал(а): ↑
12.11.2014 13:45
хотелось бы автоматизировать все, чтобы он сам перекидывал бекапы на сервер самбы
Ну не через mc же бекапы будут перекидываться? Обычным cp пробовали копировать?
Пишите правильно:
| в консоли вку́пе (с чем-либо) в общем вообще |
в течение (часа) новичок нюанс по умолчанию |
приемлемо проблема пробовать трафик |
-
drBatty
- Сообщения: 8735
- Статус: GPG ID: 4DFBD1D6 дом горит, козёл не видит…
- ОС: Slackware-current
- Контактная информация:
Re: Ошибка при копировании
Сообщение
drBatty » 13.11.2014 16:20
Zloydog писал(а): ↑
12.11.2014 13:45
То есть перекидывать из под пользователя?
естественно. Для бекапов проще из под рута(хотя и опасно), НО: обязательно в простого пользователя. Этому удалённому пользователю можно назначить права write only, а также, как я их называю, «янтарные каталоги» сделать, это в ext4 атрибут append only, что-бы бекап нельзя было удалить с другой системы.
Zloydog писал(а): ↑
12.11.2014 13:45
Ну вообще я по SSH и так цепляюсь к серверам.
дык и смысл?
Zloydog писал(а): ↑
12.11.2014 13:45
но хотелось бы автоматизировать все, чтобы он сам перекидывал бекапы на сервер самбы
я не пойму: зачем вам вообще SMB и mc в данной задаче? Аж две лишних сущности.
-
Zloydog
- Сообщения: 17
- ОС: Linux Debian
Re: Ошибка при копировании
Сообщение
Zloydog » 14.11.2014 11:30
drBatty писал(а): ↑
13.11.2014 16:20
Zloydog писал(а): ↑
12.11.2014 13:45
То есть перекидывать из под пользователя?
естественно. Для бекапов проще из под рута(хотя и опасно), НО: обязательно в простого пользователя. Этому удалённому пользователю можно назначить права write only, а также, как я их называю, «янтарные каталоги» сделать, это в ext4 атрибут append only, что-бы бекап нельзя было удалить с другой системы.
Zloydog писал(а): ↑
12.11.2014 13:45
Ну вообще я по SSH и так цепляюсь к серверам.
дык и смысл?
Zloydog писал(а): ↑
12.11.2014 13:45
но хотелось бы автоматизировать все, чтобы он сам перекидывал бекапы на сервер самбы
я не пойму: зачем вам вообще SMB и mc в данной задаче? Аж две лишних сущности.
Так и пробовал кидать из под рута на пользователя..
В смысле смысл? А как еще цепляться то к серверам с винды в кабинете?) в кабинете винда стоит, а сервера в другом конце здания там Linux
Да вот решил МС попробовать чтобы удаленно скопировать, так то все время ножками до сервером и накопитель цепляю)
Или так попробовать, через «scp -r user@server1:/var/www/html/ /backup»?
-
Bizdelnick
- Модератор
- Сообщения: 20347
- Статус: nulla salus bello
- ОС: Debian GNU/Linux
Re: Ошибка при копировании
Сообщение
Bizdelnick » 14.11.2014 12:05
Zloydog писал(а): ↑
14.11.2014 11:30
Или так попробовать, через «scp -r user@server1:/var/www/html/ /backup»?
Да хотя бы так. Хотя лучше, конечно, rsync, если всё время в одно и то же место копируете.
Пишите правильно:
| в консоли вку́пе (с чем-либо) в общем вообще |
в течение (часа) новичок нюанс по умолчанию |
приемлемо проблема пробовать трафик |
-
BigBrother
- Сообщения: 436
- Статус: ¯_(ツ)_/¯
- ОС: linux based
Re: Ошибка при копировании
Сообщение
BigBrother » 23.11.2014 23:47
Zloydog писал(а): ↑
11.11.2014 17:32
Ситуация такая — подключился со шлюза на котором стоит Debian к самбе с помощью Midnight Commander через Shell. Стал перекидывать архивы бекапов и Midnight Commander выдает ошибки «Не возможно сменить владельца целевого файла. Ошибка удаленного вводавывода 121» и потом вторая «Невозможно сменить режим доступа целевого файла»
У mc есть опция «сохранять атрибуты» при копировании, попробуйте ее убрать.
При копировании через Shell link соединение в Midnight Сommander с Debian на Ubuntu, появлялась ошибка: cannot chown target file remote i/o error 121.
Такая ошибка говорит о том, что MC (а может и не он) не может перенести права на файл, на удаленную систему. Для того чтобы все же удалось скопировать, необходимо в диалоге копирования MC убрать галочку с пункта: preserve Attributes
Автор: Виталий Орлов
| Рейтинг: 4/5 |
Теги: midnight commander
|
1 / 1 / 0 Регистрация: 16.10.2012 Сообщений: 37 |
|
|
1 |
|
Ошибка при копировании12.11.2014, 09:16. Показов 8182. Ответов 9
Ситуация такая — подключился со шлюза на котором стоит Debian к самбе с помощью Midnight Commander через Shell. Стал перекидывать архивы бекапов и Midnight Commander выдает ошибки «Не возможно сменить владельца целевого файла. Ошибка удаленного вводавывода 121» и потом вторая «Невозможно сменить режим доступа целевого файла» Сходил до сервера воткнул флешку, примонтировал и все спокойно перекинул. Но хотелось бы разобраться в чем проблема данная.
0 |
|
12703 / 7274 / 770 Регистрация: 09.09.2009 Сообщений: 28,402 |
|
|
12.11.2014, 10:38 |
2 |
|
снять птицу «сохранять атрибуты»
0 |
|
1 / 1 / 0 Регистрация: 16.10.2012 Сообщений: 37 |
|
|
12.11.2014, 13:46 [ТС] |
3 |
|
Не вариант, пробовал, тогда он вообще не копирует. При снятой галке он не выдает ошибки но и не копирует.. то есть идет вид копирования, а в той папке пусто.
0 |
|
12703 / 7274 / 770 Регистрация: 09.09.2009 Сообщений: 28,402 |
|
|
12.11.2014, 15:34 |
4 |
|
как раз таки и вариант
0 |
|
1 / 1 / 0 Регистрация: 16.10.2012 Сообщений: 37 |
|
|
14.11.2014, 11:22 [ТС] |
5 |
|
При снятой галке не копирует, так же наблюдаю пустую папку куда копирую
0 |
|
Модератор
8391 / 3145 / 106 Регистрация: 24.05.2011 Сообщений: 14,306 Записей в блоге: 8 |
|
|
16.11.2014, 21:01 |
6 |
|
Zloydog, А права на целевую папку?
0 |
|
Заблокирован |
|
|
17.11.2014, 06:51 |
7 |
|
Хм. Ну как я и предполагал… Не освоил шелл, а уже побежал софт собирать или даже писать…
0 |
|
1 / 1 / 0 Регистрация: 16.10.2012 Сообщений: 37 |
|
|
17.11.2014, 09:07 [ТС] |
8 |
|
права полные давал,как только не пробовал
0 |
|
Заблокирован |
|
|
17.11.2014, 09:13 |
9 |
|
Ему не права надо, а owner’a менять. Такое может только рут в общем виде(в частных можно от себя дать кому-то, но у тебя с другой системы 99% не совпадают uid/gid). Отрубай сохранение прав и ownerов при копировании.
0 |
|
1 / 1 / 0 Регистрация: 16.10.2012 Сообщений: 37 |
|
|
17.11.2014, 09:21 [ТС] |
10 |
|
Не понял маленько
0 |
I am facing problems, that pyhton throws me on my raspberry pi 3 sometimes this IOError during starting a script which is requesting data from an Arduino over I2C.
Electrical connection is perfect so this is not the issues.
Furthermore I also dont get any errors while using i2cget -y 1 0x04
Only the python scripts sucks sometime and I dont know why.
This is my Arduino Code:
I register an onReceive and an onRequestEvent.
onReceive Callback will define what kind of data should be send back to the raspberry.
onRequest Callback does the response.
#include <CommonFunction.h>
#include <Wire.h>
#define I2C_ADDRESS 0x4
commonFunc GetCountsEverySecond;
int g_iOnRequestActionCode = 0;
unsigned long g_lSecondsSinceStart = 0;
void setup()
{
Wire.begin(I2C_ADDRESS);
Wire.onRequest(sendDataOverI2CGateway);
Wire.onReceive(defineOnRequestAction);
}
void loop()
{
tickSeconds();
}
void tickSeconds()
{
if (GetCountsEverySecond.TimeTriggerAt(1000))
{
g_lSecondsSinceStart++;
}
}
void sendOperationTimeDataOverI2C()
{
unsigned long longInt = g_lSecondsSinceStart;
byte size = sizeof(longInt);
byte arr[size];
for (int i = 0; i < size; i++)
{
int iBitShift = 8 * (size - i - 1);
if (iBitShift >= 8)
arr[i] = ((longInt >> iBitShift) & 0xFF);
else
arr[i] = (longInt & 0xFF);
}
Wire.write(arr, size);
g_bI2CSending = true;
}
void sendDataOverI2CGateway()
{
switch(g_iOnRequestActionCode)
{
case 0:
sendRainDataOverI2C();
break;
case 1: // send firmware version
sendVersionDataOverI2C();
break;
case 2: // send operation time of arduino in seconds from start
sendOperationTimeDataOverI2C();
break;
default: break;
}
}
void defineOnRequestAction(int iBuffer)
{
while (Wire.available())
{
g_iOnRequestActionCode = Wire.read();
}
}
Here is my python Code.
Pretty straight forward but it causes some headache.
import smbus
import time
bus = smbus.SMBus(1)
while True:
data = bus.read_i2c_block_data(0x04,0x02,4)
result = 0
for b in data:
result = result * 256 + int(b)
print(result)
time.sleep(1)
After executing my python script I am getting sometime this error:
pi@WeatherStation:~/workspace $ sudo python readTimeOperationData.py
Traceback (most recent call last):
File "readTimeOperationData.py", line 5, in <module>
data = bus.read_i2c_block_data(0x04,0x02,4)
IOError: [Errno 121] Remote I/O error
Can anyone help me to fix this issue?
Cheers Dieter
- Печать
Страницы: [1] Вниз
Тема: не могу подсоединится по SSh (Прочитано 1391 раз)
0 Пользователей и 1 Гость просматривают эту тему.
dj—alex
-bash: /etc/bash_completion: Ошибка ввода/вывода
-bash: /etc/bash.bashrc: Ошибка ввода/вывода
через scp и sftp выдает туже фигню…
подскажите что сделать
есть возможность зайти в серверную,но всего 1 раз.
2 будетнескоро.
podkovyrsty
Шаг за шагом можно достичь цели.
dj—alex
тупо перезапустилмашину — всёзаработало.
точно надо проверять?
podkovyrsty
Вам по английски написать?
Запустите fschk
Шаг за шагом можно достичь цели.
Denis89
Привет всем!
Поставил Ubuntu 10 версию — в надежде облегчить работу в сети- в частности подключить свой N900 по ssh .нашел в меню- программу для этого — ввожу root@айпи телефона, логин и пароль, — жму коннект — просит пароль- какой?? дело в том что программа winSCP с этими же входными данными без проблем подключает меня к N900 — правда -в программе я еще ввожу специальный «приват — ключ» — который генерируется один раз и сохраняется на диске.
Пожалуйста- подскажите, где копать ? ) что за дополнительный пароль спрашивает программа? ( название программы забыл- но она в стандартном меню убунты)
Спасибо.
podkovyrsty
Дык а ключ то ей кто давать будет? (:
А пароль она просит от учетной записи root
Шаг за шагом можно достичь цели.
Denis89
спасибо , но не помогло , правда. Вводил пароль , что при запуске требует- все равно пишет — логин фэйлд ( Программа называет bareFTP версия 0.3.4.
podkovyrsty
если вы с убунты пробуете, попробуйте для начала просто по ssh зайти
откройте терминал и наберите
ssh -v root@ip_адрес_нокии
Шаг за шагом можно достичь цели.
- Печать
Страницы: [1] Вверх
Re: Забавный баг с удалённой машиной. Что с ней случилось и как исправить?
А точно в логах пусто?
Если в /var/log/everything/current есть свежие записи, то, судя по всему, с самой FS всё ок:
…
Тьфу, я тормоз. Не на той машине смотрел. dmesg тут, действительно, чист. А вот в everything такое:
Oct 18 21:06:52 [kernel] mptscsih: ioc0: attempting task abort! (sc=ffff8801ff069980)
Oct 18 21:06:52 [kernel] sd 4:0:0:0: [sda] CDB: cdb[0]=0x2a: 2a 00 03 e8 79 3e 00 00 08 00
Oct 18 21:06:52 [kernel] mptscsih: ioc0: WARNING - TM Handler for type=1: IOC Not operational (0xffffffff)!
Oct 18 21:06:52 [kernel] mptscsih: ioc0: WARNING - Issuing HardReset!!
Oct 18 21:06:52 [kernel] mptbase: ioc0: Initiating recovery
Oct 18 21:06:52 [kernel] mptbase: ioc0: WARNING - Unexpected doorbell active!
Oct 18 21:06:52 [kernel] sd 4:0:0:0: mptscsih: ioc0: completing cmds: fw_channel 0, fw_id 0, sc=ffff8801ff069480, mf = ffff88022e204280, idx=35
Oct 18 21:06:52 [kernel] sd 4:0:0:0: mptscsih: ioc0: completing cmds: fw_channel 0, fw_id 0, sc=ffff88022e6f4980, mf = ffff88022e206880, idx=81
Oct 18 21:06:52 [kernel] sd 4:0:0:0: mptscsih: ioc0: completing cmds: fw_channel 0, fw_id 0, sc=ffff88022e6f4880, mf = ffff88022e208580, idx=bb
Oct 18 21:06:52 [kernel] sd 4:0:0:0: mptscsih: ioc0: completing cmds: fw_channel 0, fw_id 0, sc=ffff8801ff069180, mf = ffff88022e209f00, idx=ee
Oct 18 21:06:52 [kernel] sd 4:0:0:0: mptscsih: ioc0: completing cmds: fw_channel 0, fw_id 0, sc=ffff8801ff069980, mf = ffff88022e20fc00, idx=1a8
Oct 18 21:07:52 [kernel] mptbase: ioc0: WARNING - ResetHistory bit failed to clear!
Oct 18 21:07:52 [kernel] mptbase: ioc0: ERROR - Diagnostic reset FAILED! (ffffffffh)
Oct 18 21:07:52 [kernel] mptbase: ioc0: WARNING - NOT READY!
Oct 18 21:07:52 [kernel] mptbase: ioc0: WARNING - Cannot recover rc = -1!
Oct 18 21:07:52 [kernel] mptscsih: ioc0: WARNING - TMHandler: HardReset FAILED!!
Oct 18 21:07:52 [kernel] mptscsih: ioc0: task abort: FAILED (sc=ffff8801ff069980)
Oct 18 21:07:52 [kernel] mptscsih: ioc0: attempting task abort! (sc=ffff88022e6f4880)
Oct 18 21:07:52 [kernel] sd 4:0:0:0: [sda] CDB: cdb[0]=0x2a: 2a 00 03 e8 f4 c6 00 00 08 00
Oct 18 21:07:52 [kernel] mptscsih: ioc0: task abort: SUCCESS (sc=ffff88022e6f4880)
Oct 18 21:08:02 [kernel] mptscsih: ioc0: attempting task abort! (sc=ffff88022e6f4880)
Oct 18 21:08:02 [kernel] sd 4:0:0:0: [sda] CDB: cdb[0]=0x0: 00 00 00 00 00 00
Oct 18 21:08:02 [kernel] mptscsih: ioc0: task abort: SUCCESS (sc=ffff88022e6f4880)
Oct 18 21:08:02 [kernel] mptscsih: ioc0: attempting task abort! (sc=ffff88022e6f4980)
Oct 18 21:08:02 [kernel] sd 4:0:0:0: [sda] CDB: cdb[0]=0x2a: 2a 00 03 ed 30 76 00 00 08 00
Oct 18 21:08:02 [kernel] mptscsih: ioc0: task abort: SUCCESS (sc=ffff88022e6f4980)
Oct 18 21:08:12 [kernel] mptscsih: ioc0: attempting task abort! (sc=ffff88022e6f4980)
Oct 18 21:08:12 [kernel] sd 4:0:0:0: [sda] CDB: cdb[0]=0x0: 00 00 00 00 00 00
Oct 18 21:08:12 [kernel] mptscsih: ioc0: task abort: SUCCESS (sc=ffff88022e6f4980)
Oct 18 21:08:12 [kernel] mptscsih: ioc0: attempting task abort! (sc=ffff8801ff069480)
Oct 18 21:08:12 [kernel] sd 4:0:0:0: [sda] CDB: cdb[0]=0x2a: 2a 00 03 f0 68 36 00 00 08 00
Oct 18 21:08:12 [kernel] mptscsih: ioc0: task abort: SUCCESS (sc=ffff8801ff069480)
Oct 18 21:08:14 [named] client 94.25.128.68#7031: query (cache) 'www.goodfly.ru/A/IN' denied
Oct 18 21:08:15 [named] client 94.25.208.69#33011: query (cache) 'www.goodfly.ru/A/IN' denied
Oct 18 21:08:22 [kernel] mptscsih: ioc0: attempting task abort! (sc=ffff8801ff069480)
Oct 18 21:08:22 [kernel] sd 4:0:0:0: [sda] CDB: cdb[0]=0x0: 00 00 00 00 00 00
Oct 18 21:08:22 [kernel] mptscsih: ioc0: task abort: SUCCESS (sc=ffff8801ff069480)
Oct 18 21:08:22 [kernel] mptscsih: ioc0: attempting task abort! (sc=ffff8801ff069180)
Oct 18 21:08:22 [kernel] sd 4:0:0:0: [sda] CDB: cdb[0]=0x2a: 2a 00 03 fa 39 de 00 00 08 00
Oct 18 21:08:22 [kernel] mptscsih: ioc0: task abort: SUCCESS (sc=ffff8801ff069180)
Oct 18 21:08:32 [kernel] mptscsih: ioc0: attempting task abort! (sc=ffff8801ff069180)
Oct 18 21:08:32 [kernel] sd 4:0:0:0: [sda] CDB: cdb[0]=0x0: 00 00 00 00 00 00
Oct 18 21:08:32 [kernel] mptscsih: ioc0: task abort: SUCCESS (sc=ffff8801ff069180)
Oct 18 21:08:32 [kernel] mptscsih: ioc0: attempting target reset! (sc=ffff8801ff069980)
Oct 18 21:08:32 [kernel] sd 4:0:0:0: [sda] CDB: cdb[0]=0x2a: 2a 00 03 e8 79 3e 00 00 08 00
Oct 18 21:08:32 [kernel] mptscsih: ioc0: target reset: FAILED (sc=ffff8801ff069980)
Oct 18 21:08:32 [kernel] mptscsih: ioc0: attempting bus reset! (sc=ffff8801ff069980)
Oct 18 21:08:32 [kernel] sd 4:0:0:0: [sda] CDB: cdb[0]=0x2a: 2a 00 03 e8 79 3e 00 00 08 00
Oct 18 21:08:35 [named] client 83.169.185.33#46884: query (cache) 'goodfly.ru/A/IN' denied
Oct 18 21:08:35 [named] client 83.169.185.33#43016: query (cache) 'goodfly.ru/A/IN' denied
Oct 18 21:08:43 [kernel] mptscsih: ioc0: bus reset: FAILED (sc=ffff8801ff069980)
Oct 18 21:08:43 [kernel] mptscsih: ioc0: attempting host reset! (sc=ffff8801ff069980)
Oct 18 21:08:43 [kernel] mptbase: ioc0: Initiating recovery
Oct 18 21:08:43 [kernel] mptbase: ioc0: WARNING - Unexpected doorbell active!
Oct 18 21:08:46 [named] zone wikilinks.ru/IN: refresh: retry limit for master 85.30.226.178#53 exceeded (source 0.0.0.0#0)
Oct 18 21:08:46 [named] zone wikilinks.ru/IN: Transfer started.
Походу, проблема с контроллером. Странно только, что /home работает, а другие разделы на том же винте и контроллере — нет…
★★★★★
(19.10.09 11:07:01 MSD)
- Ссылка
Ошибка при копировании (!)
Модератор: SLEDopit
-
Zloydog
- Сообщения: 17
- ОС: Linux Debian
Ошибка при копировании
Ситуация такая — подключился со шлюза на котором стоит Debian к самбе с помощью Midnight Commander через Shell. Стал перекидывать архивы бекапов и Midnight Commander выдает ошибки «Не возможно сменить владельца целевого файла. Ошибка удаленного вводавывода 121» и потом вторая «Невозможно сменить режим доступа целевого файла»
Сходил до сервера воткнул флешку, примонтировал и все спокойно перекинул. Но хотелось бы разобраться в чем проблема данная.
-
drBatty
- Сообщения: 8735
- Статус: GPG ID: 4DFBD1D6 дом горит, козёл не видит…
- ОС: Slackware-current
- Контактная информация:
Re: Ошибка при копировании
Сообщение
drBatty » 12.11.2014 09:31
Zloydog писал(а): ↑
11.11.2014 17:32
Ситуация такая — подключился со шлюза на котором стоит Debian к самбе с помощью Midnight Commander через Shell. Стал перекидывать архивы бекапов
КУДА копировали?
Zloydog писал(а): ↑
11.11.2014 17:32
Но хотелось бы разобраться в чем проблема данная.
проблема в том, что какие-то атрибуты файлов в удалённой системе не поддерживаются.
Zloydog писал(а): ↑
11.11.2014 17:32
воткнул флешку
это с FAT, да? Так там никакие атрибуты не поддерживаются, только временной штамп, и то 32х битный. Вот вы их все успешно потеряли.
Hint: что-бы не потерять атрибуты(основные, такие как права доступа и владельца), используйте tar-архив для передачи, ну или rsync over ssh тоже хорошо работает.
-
Zloydog
- Сообщения: 17
- ОС: Linux Debian
Re: Ошибка при копировании
Сообщение
Zloydog » 12.11.2014 09:42
drBatty писал(а): ↑
12.11.2014 09:31
Zloydog писал(а): ↑
11.11.2014 17:32
Ситуация такая — подключился со шлюза на котором стоит Debian к самбе с помощью Midnight Commander через Shell. Стал перекидывать архивы бекапов
КУДА копировали?
Zloydog писал(а): ↑
11.11.2014 17:32
Но хотелось бы разобраться в чем проблема данная.
проблема в том, что какие-то атрибуты файлов в удалённой системе не поддерживаются.
Zloydog писал(а): ↑
11.11.2014 17:32
воткнул флешку
это с FAT, да? Так там никакие атрибуты не поддерживаются, только временной штамп, и то 32х битный. Вот вы их все успешно потеряли.
Hint: что-бы не потерять атрибуты(основные, такие как права доступа и владельца), используйте tar-архив для передачи, ну или rsync over ssh тоже хорошо работает.
Копировал с со шлюза (Debian) на Samba файлообменник (debian). Архив создал 1.tar.gz
-
drBatty
- Сообщения: 8735
- Статус: GPG ID: 4DFBD1D6 дом горит, козёл не видит…
- ОС: Slackware-current
- Контактная информация:
Re: Ошибка при копировании
Сообщение
drBatty » 12.11.2014 10:04
Zloydog
очень плохая идея копировать файлы удалённо от/в root-доступ. Это РЕШЕТО.
Так никто не делает, потому и не тестирует никто. А если вы копируете обычным пользователем, то владелец автоматически меняется на получателя. Причём AFAIK в mc всё вроде-бы менялось без ошибок.
Ваша проблема скорее всего в том, что пользователи разные, и mc почему-то хочет сменить владельца файла на отправителя, как оно на локальной системе.
А зачем вы используете именно SMB соединение, ведь оно предназначено лишь для Windows™ систем? Нельзя-ли использовать OpenSSH?
Ещё вопрос: надеюсь вы применяете «SMB соединение», а не «FiSH»?
-
Zloydog
- Сообщения: 17
- ОС: Linux Debian
Re: Ошибка при копировании
Сообщение
Zloydog » 12.11.2014 13:45
drBatty писал(а): ↑
12.11.2014 10:04
Zloydog
очень плохая идея копировать файлы удалённо от/в root-доступ. Это РЕШЕТО.Так никто не делает, потому и не тестирует никто. А если вы копируете обычным пользователем, то владелец автоматически меняется на получателя. Причём AFAIK в mc всё вроде-бы менялось без ошибок.
Ваша проблема скорее всего в том, что пользователи разные, и mc почему-то хочет сменить владельца файла на отправителя, как оно на локальной системе.
А зачем вы используете именно SMB соединение, ведь оно предназначено лишь для Windows™ систем? Нельзя-ли использовать OpenSSH?
Ещё вопрос: надеюсь вы применяете «SMB соединение», а не «FiSH»?
То есть перекидывать из под пользователя? Ну вообще я по SSH и так цепляюсь к серверам..Физически их нет рядом. да smb. Я пробовал менял у архива владельца и группу на те что на папку в которую скидваю тоже не хочет.. мне конечно не лень раз в неделю дойти до сервера подцепить флешку и бекап сделать, но хотелось бы автоматизировать все, чтобы он сам перекидывал бекапы на сервер самбы
-
Bizdelnick
- Модератор
- Сообщения: 19763
- Статус: nulla salus bello
- ОС: Debian GNU/Linux
Re: Ошибка при копировании
Сообщение
Bizdelnick » 12.11.2014 14:30
Zloydog писал(а): ↑
12.11.2014 13:45
хотелось бы автоматизировать все, чтобы он сам перекидывал бекапы на сервер самбы
Ну не через mc же бекапы будут перекидываться? Обычным cp пробовали копировать?
Пишите правильно:
| в консоли вку́пе (с чем-либо) в общем вообще |
в течение (часа) новичок нюанс по умолчанию |
приемлемо проблема пробовать трафик |
-
drBatty
- Сообщения: 8735
- Статус: GPG ID: 4DFBD1D6 дом горит, козёл не видит…
- ОС: Slackware-current
- Контактная информация:
Re: Ошибка при копировании
Сообщение
drBatty » 13.11.2014 16:20
Zloydog писал(а): ↑
12.11.2014 13:45
То есть перекидывать из под пользователя?
естественно. Для бекапов проще из под рута(хотя и опасно), НО: обязательно в простого пользователя. Этому удалённому пользователю можно назначить права write only, а также, как я их называю, «янтарные каталоги» сделать, это в ext4 атрибут append only, что-бы бекап нельзя было удалить с другой системы.
Zloydog писал(а): ↑
12.11.2014 13:45
Ну вообще я по SSH и так цепляюсь к серверам.
дык и смысл?
Zloydog писал(а): ↑
12.11.2014 13:45
но хотелось бы автоматизировать все, чтобы он сам перекидывал бекапы на сервер самбы
я не пойму: зачем вам вообще SMB и mc в данной задаче? Аж две лишних сущности.
-
Zloydog
- Сообщения: 17
- ОС: Linux Debian
Re: Ошибка при копировании
Сообщение
Zloydog » 14.11.2014 11:30
drBatty писал(а): ↑
13.11.2014 16:20
Zloydog писал(а): ↑
12.11.2014 13:45
То есть перекидывать из под пользователя?
естественно. Для бекапов проще из под рута(хотя и опасно), НО: обязательно в простого пользователя. Этому удалённому пользователю можно назначить права write only, а также, как я их называю, «янтарные каталоги» сделать, это в ext4 атрибут append only, что-бы бекап нельзя было удалить с другой системы.
Zloydog писал(а): ↑
12.11.2014 13:45
Ну вообще я по SSH и так цепляюсь к серверам.
дык и смысл?
Zloydog писал(а): ↑
12.11.2014 13:45
но хотелось бы автоматизировать все, чтобы он сам перекидывал бекапы на сервер самбы
я не пойму: зачем вам вообще SMB и mc в данной задаче? Аж две лишних сущности.
Так и пробовал кидать из под рута на пользователя..
В смысле смысл? А как еще цепляться то к серверам с винды в кабинете?) в кабинете винда стоит, а сервера в другом конце здания там Linux
Да вот решил МС попробовать чтобы удаленно скопировать, так то все время ножками до сервером и накопитель цепляю)
Или так попробовать, через «scp -r user@server1:/var/www/html/ /backup»?
-
Bizdelnick
- Модератор
- Сообщения: 19763
- Статус: nulla salus bello
- ОС: Debian GNU/Linux
Re: Ошибка при копировании
Сообщение
Bizdelnick » 14.11.2014 12:05
Zloydog писал(а): ↑
14.11.2014 11:30
Или так попробовать, через «scp -r user@server1:/var/www/html/ /backup»?
Да хотя бы так. Хотя лучше, конечно, rsync, если всё время в одно и то же место копируете.
Пишите правильно:
| в консоли вку́пе (с чем-либо) в общем вообще |
в течение (часа) новичок нюанс по умолчанию |
приемлемо проблема пробовать трафик |
-
BigBrother
- Сообщения: 436
- Статус: ¯_(ツ)_/¯
- ОС: linux based
Re: Ошибка при копировании
Сообщение
BigBrother » 23.11.2014 23:47
Zloydog писал(а): ↑
11.11.2014 17:32
Ситуация такая — подключился со шлюза на котором стоит Debian к самбе с помощью Midnight Commander через Shell. Стал перекидывать архивы бекапов и Midnight Commander выдает ошибки «Не возможно сменить владельца целевого файла. Ошибка удаленного вводавывода 121» и потом вторая «Невозможно сменить режим доступа целевого файла»
У mc есть опция «сохранять атрибуты» при копировании, попробуйте ее убрать.
При работе с SSH-соединениями нередко возникают разного рода ошибки. Это могут быть неполадки с соединением, авторизацией и т. д. Но есть также категория ошибок работы SSH, которые возникают на уровне протокола. Зачастую они имеют место быть при неумелом обращении, собственно, с самим протоколом SSH, например неправильное использование ключей шифрования. Но также могут быть и реальные неполадки, связанные с некорректной конфигурацией сервера или клиента SSH, что отражается на работе, в частности, протокола. Именно о таких неполадках, а также способах их выявления и устранения пойдёт речь в данной статье.
Содержание
- Какие бывают ошибки протокола SSH?
- Невозможность проверки ключа хоста
- Закрытие или сброс соединения
- Ошибка взаимодействия с хостом
- Заключение
Когда SSH-клиенты получают ошибки сброса соединений, неполадки с шифрованием, а также наблюдаются проблемы, связанные с «неизвестным» или «изменённым» хостом, то это, как правило, ошибки работы протокола SSH. Подобного рода неполадки часто возникают на этапе согласования зашифрованного соединения протоколом SSH посредством создания доверия между сервером и клиентом.
Невозможность проверки ключа хоста
При создании SSH-соединения протокол требует, чтобы стороны идентифицировали себя. Бывает так, что от сервера поступает следующая ошибка:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the ECDSA key sent by the remote host is SHA256:doBAKL304WyMd8hnFc9a29r3nX9okS9BlrBJcHtuyNk. Please contact your system administrator. Add correct host key in /root/.ssh/known_hosts to get rid of this message. Offending ECDSA key in /root/.ssh/known_hosts:14 ECDSA host key for 212.45.27.201 has changed and you have requested strict checking. Host key verification failed.
Эта ошибка может возникать по нескольким причинам:
- переустановка SSH-сервера и неполная его конфигурация;
- восстановление сервера из резервной копии;
- изменение IP-адреса сервера.
Очистка ключей хостов помогает решить эту проблему. Сами эти ключи хранятся на стороне клиента в файле ~/.ssh/known_hosts. Для очистки можно удалить все записи вручную. Либо можно использовать команду:
$ ssh-keygen -R host_ip
Эта команда попытается очистить соответствующую информацию о ключе хоста в файле known_hosts:
Host 123.123.123.123 found: line 14 /home/john/.ssh/known_hosts updated. Original contents retained as /home/john/.ssh/known_hosts.old
После этих действий можно попробовать снова выполнить подключение к серверу SSH.
Закрытие или сброс соединения
Бывает так, что соединение с SSH-сервером устанавливается, однако на этапе проверки ключей сбрасывается. Эта ошибка выглядит следующим образом:
Connection closed by 123.123.123.123 port 22
Часто такая ошибка возникает по нескольким причинам:
- программный сбой работы SSH-сервера или он не запущен;
- невозможность инициализировать соединение из-за отсутствия или недоступности ключей.
В данном случае необходимо проверить корректность заданной конфигурации сервера, проверить, запущен ли сам сервис. Если же с сервисом всё в порядке, то необходимо удостовериться, что SSH-ключи доступны для использования сервером. Если они отсутствуют, то необходимо их сгенерировать.
В данном случае необходимо проверить, есть ли в каталоге /etc/ssh набор файлов с именами sshd_host_*_key. Один из них должен иметь расширение *.pub.
В случае, если таких файлов нет, их нужно сгенерировать:
$ ssh-keygen -A ssh-keygen: generating new host keys: RSA DSA ECDSA ED25519
Теперь можно снова попытаться подключиться к серверу.
Ошибка взаимодействия с хостом
Для работы протокола SSH на этапе его инициализации генерируется общий закрытый ключ. Он создаётся на основе шифрования, которое согласуется при создании подключения между сервером и клиентом. Иногда на этом этапе возникают несоответствия и на стороне клиента это приводит к следующей ошибке:
Unable to negotiate with 123.123.123.123: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1
Эта ошибка говорит о том, что сервер и клиент друг друга «не понимают». Это может быть вызвано следующими причинами:
- список шифрования сервера был изменён или сервер его не поддерживает;
- различные реализации (версии) протокола SSH на сервере и у клиента.
Как можно видеть, для устранения этой ошибки необходимо привести в соответствие версию клиента SSH, а также настроить шифрование для него. Если сервер использует устаревший метод шифрования, например SHA1, а у клиента по-умолчанию задействованы более совершенные методы, то это также будет вызывать ошибки протокола SSH. Для начала необходимо выяснить, действительно ли у сервера и клиента используются разные методы шифрования.
Для клиента использование методов шифрования можно настроить, используя опцию KexAlgorithms:
$ openssh -o KexAlgorithms=+diffie-hellman-group1-sha1 root@your_server_ip
Эта проблема не такая распространённая, поскольку возникает, когда версия реализации SSH-клиента более новая, чем используемая на сервере.
Заключение
В заключение нужно отметить, что рассмотренные неполадки и способы их устранения являются самыми распространёнными. Если для конкретного случая вышеописанное не помогает устранить проблему в работе SSH, то возможно, неполадка связана не с протоколом, а с другой областью, например с неполадками установления подключения по SSH.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Я не могу войти в свой sshfs, хотя я уверен, что соединение в порядке и место назначения существует. Каждая файловая операция завершается с ошибкой Input/output error .
Выводы sshfs:
$ sshfs -p 7292 server:/in/vm/dir ~/vm_dir -d
FUSE library version: 2.9.2
nullpath_ok: 0
nopath: 0
utime_omit_ok: 0
unique: 1, opcode: INIT (26), nodeid: 0, insize: 56, pid: 0
INIT: 7.20
flags=0x000017fb
max_readahead=0x00020000
INIT: 7.19
flags=0x00000011
max_readahead=0x00020000
max_write=0x00020000
max_background=0
congestion_threshold=0
unique: 1, success, outsize: 40
unique: 2, opcode: GETATTR (3), nodeid: 1, insize: 56, pid: 2287
getattr /
unique: 3, opcode: OPENDIR (27), nodeid: 1, insize: 48, pid: 21063
unique: 3, success, outsize: 32
unique: 4, opcode: LOOKUP (1), nodeid: 1, insize: 57, pid: 2288
LOOKUP /.xdg-volume-info
getattr /.xdg-volume-info
unique: 2, success, outsize: 120
unique: 4, error: -2 (No such file or directory), outsize: 16
unique: 5, opcode: RELEASEDIR (29), nodeid: 1, insize: 64, pid: 0
unique: 5, success, outsize: 16