Ну кто знает что и как там у него устроено? Может кроме miracle есть и другие юзеры, к которым nginx (процесс) должен иметь доступ. Он сейчас поменяет, это заработает, а остальное перестанет.
Так не делается.
Важно понимать всю структуру как там что устроено сейчас от начала (что принимает запросы из вне) до конца (файлов).
Во-первых web-сервер работает один или пара (nginx+apache), от каких пользователей работают они. Apache с mod_php или же php по-другому как-то выполняется независимо? Надо всю цепочку смотреть, что работает и от какого пользователя. И уже после этого будет понимание какие права должны быть на файлах/папках чтоб все работало.
Пример как сделано у меня: есть пара общий nginx'ов (раздельно для http и https, но сейчас не об этом), работающих от пользователя www.
Есть множество обычных бесправных пользователей (u), от имени которых запущены их процессы mysql и apache/mod_php.
Соответственно в домашних каталогах пользователей везде последняя цифра 0 - 660 на файлы и 770 на папки (owner:group - u:u)
Таким образом никаким "other" никуда доступа не дано и не нужно. При этом ни у баз, ни у php нет проблем с доступом куда-либо в рамках этого пользователя. Ftp также естественно переключается на этого пользователя после авторизации, т.е. все что он закинет - также станет 770/660 и все будет работать.
Но можно заметить, что у nginx должны возникнуть проблемы с доступом к статике, он же от другого пользователя работает. Для этого www добавлен в группу к каждому u. Скриптов он сам никаких не исполняет и доступа напрямую к конфигам у u-пользователей нет, потому дырки в безопасности вроде как не должно быть. Таким образом frontend имеет доступ ко всем, а backend только туда, от чьего имени он запущен.
Когда же народ, начитавшись советов из интернетов, бездумно заводит зоопарк из пользователей и процессов, не осознавая кому и куда нужен доступ, куда он есть и куда нету... что-то не работает - тупо 777 на все и о чудо, все работает... А потом объявления и темы - помогите, взломали 😐 Это конечно не правильно.
Не вырываем из контекста!
У меня - нет. У меня последние везде нолики.
Человек сказал же не трогаем owner и group, почему не дает записать ничего когда стоит 6ка на папку - вот поэтому (статья выше). Чтоб записывать в папку, у этого пользователя (будт то owner, group или other) должен быть доступ read+write+exec.
А вообще да, согласен что там все в корне не правильно настроено раз нужно давать всем на запись доступ. Но это уже как говорится, совсем другая история...
Тут же конкретный вопрос - конкретный ответ: 6 на папку не даст записать в нее ничего.
Не важно какая ОС, не важно в данном случае от какого пользователя что запускается.
Ответ - да. Надо просто принять как данность, что для того чтоб записать что-то в каталог у него должна быть 7ка. Т.е. по сути используем 5 если только на чтение нужно предоставить доступ (read+exec) и используем 7 если и на запись (read+exec+write), ну и 0 если не давать доступа.
Читаем кому интересно:
https://it.wikireading.ru/11296
Ну есть конечно ощущение, что root права таким юзерам вообще нельзя выдавать 😐
Не надо клацать что-попало... надо понимать каждую букву, что она означает и что делает.
На пред. странице вижу -h baza написано - это означает подключиться к хосту с именем baza. И такой хост похоже не найден. baza - это видимо имя базы?
Mysql же видимо на localhost'е работает, вот и не надо там никаких ключей -h писать. Просто:
распаковать сперва (если файл базы в виде baza.sql.gz):
gunzip baza.sql.gz
потом уже распакованный .sql файл вставляем в базу baza:
mysql -u user -p'parol' baza < baza.sql
Так... болотце.
Давайте с самого начала проясним все.
Во-перых в debian 10 нет никакого php8.0-imagick
https://packages.debian.org/buster/php/
Есть лишь php-imagick, причем вроде как версии 3.4.3
Если у вас каким-то образом установлена 3.5.1, то подозреваю какими-то обходными путями. Например собрав вручную: http://pecl.php.net/package/imagick
В любом случае, версия imagick скорей всего не имеет большого значения, т.к. это лишь php модуль - прослойка между php и ImageMagick (imagemagick.org) и вот в нем должна быть поддержка нужного вам SVG
Становится еще более интересно... а у вас точно это использует... не знаю что, php скрипт видимо?
Подробности этой ошибки надо бы выяснить как-то. Если в логах нигде нет, то в самом скрипте нужно обрабатывать ошибку и показывать.
Может там вообще что-то другое использует скрипт, а не imagick? Может вообще внешнюю комманду запускает, кто знает не видя того куска скрипта где ошибка возникает.
создать какой-нть 1.php с содержимым: <?phpinfo();?>
зайти на него браузером и сразу вверху будет написано какие конфиги подгружены:
Важно сделать именно так, а не в коммандной строке php --ini запустить, т.к. это разные сущности и конфиги могут отличаться.
2мб - это лимит по-умолчанию, скорей всего надо post_max_size увеличить (но это не точно, надо поэкспериментировать, может плюс еще что-то)
Также при таком размере не помешает увеличить max_execution_time т.к. долгий будет процесс.
Быстрей всего всеж импортировать по ssh, а не php скриптами.
-p'pass&word'
или
--password=' pass&word '
Спамеры - это очень больные люди, не надо пытаться их понимать.
Нужно просто всегда использовать защиту и не замечать ущербных.
Кроме контакт форм, защищать нужно и админки всевозможные.
Только не капчу... Есть проверенная годами защита на уровне веб-сервера на все POST запросы. Пишите в личку если интересует.
Не мешайте все в одну кучу... почта, сертификаты...
"Resolving timed out" - звучит более чем однозначно - dns клиент не может определить ip домена.
Неизвестно какой домен оно пытается заресолвить, но предположим что с ним все нормально, а проблема с dns у вас.
Во-первых что в /etc/resolv.conf ? К каким dns серверам идут запросы надо уточнить. Возможно что там хостерские и они какие-то проблемные. Можно попробовать вместо них вписать 8.8.8.8 и 1.1.1.1
Во-вторых узнать бы куда тот curl запрос пытается идти и из ssh консоли глянуть "dig +short домен" (если не установлен - apt install dnsutils).
Возможно те 504 ошибки также связаны с этими dns проблемами. Нередко понаустанавливают тем/плагинчиков, которые постоянно куда-то наружу что-то шлют или запрашивают что-то из вне. Вот оно на этом этапе может стопориться и доходить до таймаута.
