|
Пользователь 102162 Посетитель Сообщений: 102 |
Добрый день. Помогите решить проблему. Не могу загрузить фотографии большого размера в подробный анонс (а точнее превышающих 128кб, вычислил методом подбора). Тестирование конфигурации показало ошибку на пункте: Загрузка файла больше 4Мб. При этом хочу заметить, что параметры php.ini в порядке. Вариант о недостатке места на диске тоже отпадает (ещё около 8ГБ свободного). Блокировка NGFIX — также отпадает (напряг техподдержку хостинга чтобы проверили параметры, а потом и вовсе его временно отключили — чтобы проверить в нем причина или нет — не помогло). И так вопрос: какие ещё настройки могут отвечать за ограничения размера загружаемого файла? |
|
Пользователь 50911 Посетитель Сообщений: 95 |
#2 0 08.11.2013 13:20:57
посмотрите там какие параметры у upload_max_filesize |
||
|
Пользователь 102162 Посетитель Сообщений: 102 |
Я же в 1 сообщении все написал, |
|
Пользователь 102162 Посетитель Сообщений: 102 |
Сам разобрался. Для тех, кто возможно, столкнется с подобной проблемой… Нужно прописать параметр FcgidMaxRequestLen, иначе нельзя через браузер загружать файлы превышающие размер 128КБ. Это ограничение возникает если сайт работает под управлением ISP Manager как CGI/FastCGI. Можно прописать данный параметр в файле httpd.conf (в моем случае, он располагался по адресу /etc/httpd/conf), в этом файле нужно отредактировать параметр, либо добавить строку FcgidMaxRequestLen 107374182 Число 107374182 позволяет загружать файлы объемом до 1Гб, делает рестарт и проблема решена. Ещё один из вариантов, можно отредактировать файл fcgid.conf <IfModule mod_fcgid.c> |
|
Пользователь 107617 Заглянувший Сообщений: 1 |
Для тех, кто использует NGINX: В файл nginx.conf, в секцию http, добавить/изменить: |
|
Пользователь 125253 Эксперт Сообщений: 435 |
Антон Водолазский
спасибо. Долго возились после переустановки ОС. Наткнулись на ваш пост) |
|
Пользователь 52657 Постоянный посетитель Сообщений: 114 |
Артем Осипов, Спасибо за подсказку. |
|
Пользователь 194259 Заглянувший Сообщений: 29 |
Большое спасибо! Проблема решена! |
|
Пользователь 336230 Заглянувший Сообщений: 3 |
Артем Осипов, Спасибо. Проблема решена. |
|
Пользователь 94067 Заглянувший Сообщений: 9 |
#10 0 07.02.2016 20:28:57 |
|
Пользователь 162578 Заглянувший Сообщений: 13 |
#11 0 10.03.2016 13:16:42 Артем Осипов,спасибо за подсказку! |
|
Пользователь 449 Постоянный посетитель Сообщений: 101 |
#12 0 04.08.2016 14:41:01
FcgidMaxRequestLen 1073741824 скорее http://webdoka.ru |
||
|
Пользователь 449 Постоянный посетитель Сообщений: 101 |
#13 0 04.08.2016 14:49:26 вот еще по теме Между тегами <IfModule mod_fcgid> и </IfModule> добавляем: IPCCommTimeout — устанавливает время доступа к скрипту от IP адреса, после которого работа процесса будет прервана. Стандартное значение — 40 секунд. |
|
Пользователь 316487 Заглянувший Сообщений: 1 |
#14 0 23.06.2017 17:56:06 Спасибо, рабочие оба варианта! |
|
Пользователь 33448 Посетитель Сообщений: 23 |
#15 0 16.01.2019 10:16:37
Антон, спасибо, помог Ваш вариант. Такой же случай — сайт работает под управлением ISP Manager как CGI/FastCGI. Добавил строку в httpd.conf и всё взлетело ) Носорог, как известно, плохо видит. Но при его весе — это не его проблемы. |
||
|
Пользователь 106725 Заглянувший Сообщений: 3 |
#16 0 18.01.2019 00:55:10 |
|
Пользователь 196067 Заглянувший Сообщений: 1 |
#17 0 14.04.2019 11:17:09
Спасибо работает |
||
|
Пользователь 2532517 Заглянувший Сообщений: 3 |
#18 0 12.05.2019 07:14:33 Спасибо! Одной проблемой стало меньше. |
|
Пользователь 4177500 Заглянувший Сообщений: 1 |
#19 0 28.07.2020 15:47:05
Прошло 7 лет, но до сих пор актуально. Спасибо |
||
|
Пользователь 3436271 Заглянувший Сообщений: 1 |
#20 0 28.09.2020 13:41:42 Спасибо большое, минус тех.поддержке особенно инженеру Александра Больнова |
|
Пользователь 2940905 Заглянувший Сообщений: 5 |
#21 0 08.04.2021 15:32:49 Помогло, спасибо! |
|
Пользователь 70906 Посетитель Сообщений: 121 |
Добрый день. Вопрос такой, почему при тестировании конфигурации выводит ошибку у пункта Загрузка файла больше 4Мб? В php.ini указаны параметры (в phpinfo тоже): Кэш битрикса очищал. Не помогает. Что делать? |
|
Администратор Сообщений: 9035 Epic fail — сказать «это так просто» и не суметь сделать |
Если приведенные Вам параметры указаны верно, то Вы ограничили загрузку файла 20 байтами. Правильно — upload_max_filesize = 20M Не надо сверлить зубы через задний проход дрелью от Сваровски |
|
Пользователь 70906 Посетитель Сообщений: 121 |
Все это установил, рестартовал, очистил кэш — без результатов. В php.ini (phpinfo) все изменения отобразились, а Битрикс Корпоративный портал их не видит. |
|
Евгений Жуков
Администратор Сообщений: 9035 Epic fail — сказать «это так просто» и не суметь сделать |
#4 0 16.01.2013 14:05:30
Вы смотрели это через админку или отдельным скриптом? Не надо сверлить зубы через задний проход дрелью от Сваровски |
||
|
Пользователь 70906 Посетитель Сообщений: 121 |
И через админку, и отдельным скриптом, ну и php.ini у меня под рукой, там внесены данные какие надо. |
|
Администратор Сообщений: 9035 Epic fail — сказать «это так просто» и не суметь сделать |
Видимо, проблема в других настройках, относящихся к аплоаду Не надо сверлить зубы через задний проход дрелью от Сваровски |
|
Пользователь 222943 Заглянувший Сообщений: 8 |
Такая же проблема, какие настройки могут быть еще? |
|
Пользователь 85801 Заглянувший Сообщений: 35 |
В настройках модулей Блоги и Форум есть поле «Максимальный размер загружаемых файлов (байт)». Может там? |
|
Пользователь 275703 Постоянный посетитель Сообщений: 183 |
Присоединяюсь к теме. |
|
Пользователь 138501 Заглянувший Сообщений: 1 |
#10 1 22.05.2015 14:36:17 Настройки PHP: http://dev.1c-bitrix.ru/support/forum/forum6/topic58299/ |
|
Пользователь 406260 Постоянный посетитель Сообщений: 29 |
#11 0 27.11.2020 09:53:12 Это ограничение даёт nginx Редактируем файл настройки nginx в Там надо добавить client_max_body_size http { или После этого перезапускаем nginx Для тех, кто использует apache2 https://dev.1c-bitrix.ru/support/forum/messages/forum6/topic58299/message305865/#message305865 |
При подготовке сервера под хостинг сайта на 1С Bitrix всплывают ошибки, с которыми я никогда не сталкивался при работе с другими CMS. Здесь я распишу что надо поменять, чтобы обмен с сайтом и upload файлов и картинок успешно выполнились.
Если честно, то Bitrix очень капризный продукт и требует очень точной настройки, для начинающих есть варианты уже с готовыми виртуальными образами, на которых развернут CentOS и Bitrix: Веб-окружение. Но если вы привыкли работать с другим дистрибутивом (лично я предпочитаю Debian и Ubuntu), то придется поковыряться в конфигах ручками.
Итак, в Apache максимальный размер файлов указывается либо в php.ini (не у всех есть доступ к этому файлу), либо напрямую в .htaccess. В моей статье Все про файл .htaccess я подробно расписывал все настройки. Ну а мы в .htaccess допишем:
php_value upload_max_filesize 10M
php_value post_max_size 10M
Я уже было решил, что проблема решена, но проверка системы также ругалась на максимальный размер файлы.
Причина оказалась в связке Nginx+Apache. Так как Nginx работает кэширующим фронт-энд сервером, то он работает изначально по своим правилам, а затем по этим правилам решает, передавать ли файл дальше в Apache или нет. Логи ясно показали ошибку
тут будет скрин или текст логов, сейчас проблема решена и естественно и нет ошибки. верну обратно и сделаю скрин
Путем недолгих поисков в интернете увидел правильные настройки виртуального хоста Nginx, с указанием максимального размера файла, который Nginx может передать бэкенд-серверу. Добавляем в /etc/nginx/sites-available/example.org.conf следующие директивы в блок настроек прокси
proxy_buffering off;
client_max_body_size 10m;
Перезапускаем службу и проверяем результат также через проверку системы Bitrix.
На сайте были такие настройки. У меня они чутка отличаются
proxy_pass http://127.0.0.1:8080/;
proxy_redirect off;
proxy_buffering off
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
client_max_body_size 10m;
client_body_buffer_size 128k;
proxy_connect_timeout 90;
proxy_send_timeout 6000;
proxy_read_timeout 6000;
proxy_buffer_size 4k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
Отблагдарить автора статьи также можно переводом, +100 вам в карму!
apache bitrix client_max_body_size htaccess nginx php_value post_max_size proxy_buffering server upload_max_filesize ошибки сайт
При работе с синхронизированными папками на Битрикс24.Диске могут возникнуть несколько типичных ошибок. Давайте рассмотрим, из-за чего они случаются и как решить возникшую проблему.
Две версии файла
Данная ошибка возникает при попытке двух пользователей загрузить обновленную версию какого-то файла из синхронизированной папки на диск.
Например, вы и ваш коллега одновременно редактируете один и тот же файл. Но он закончил раньше вас и уже сохранил его. Таким образом, на диске уже появилась новая версия документа, отличная от той, с которой вы начали работать. Данная ошибка и возникнет, когда уже вы попытаетесь его сохранить.
В таком случае, чтобы труд одного из вас не пропал даром, система не заменит файл, а сделает его копию. Потом вы сможете либо объединить их вручную, либо выбрать одну из копий документа, которую хотите оставить.
Файл заблокирован
Данная ошибка возникает при одновременной работе двух пользователей с одной Excel-таблицей, находящейся в синхронизированной папке.
Если какой-то другой сотрудник отредактировал данную таблицу, сохранил ее и синхронизировал с диском, пока вы с ней еще работаете, то у вас появится данное сообщение.
Решить данную проблему можно только организационным способом. Рекомендую сделать бекапы измененного файла в стороннем документе, не находящемся в синхронизированной папке диска. Далее оригинальный документ нужно закрыть. После этого вам с коллегами нужно принять централизованное решение, какие изменения в файл нужно внести.
Почему восстанавливается удаленный/переименованный файл?
Восстановление удаленных файлов на портале может быть связано с тем, что в момент его удаления или переименования, не все пользователи находились онлайн. Позже, когда эти пользователи включают компьютер, происходит восстановление файла с их ПК.
Также это может произойти в случае, если была запущена полная синхронизация со стороны десктопного приложения.
Если все пользователи постоянно синхронизируют Диск, такой проблемы не возникнет. Поэтому для того, чтобы удалить файл, всем пользователям нужно синхронизировать диск и удалить папку из Битрикс24.
Также проверьте, чтобы у всех сотрудников была установлена последняя версия десктопного приложения.
Спасибо, помогло!
Спасибо 
Необязательно:
Оставить отзыв о статье
Уточните, пожалуйста, почему:
Это не то, что я ищу
Очень сложно и непонятно
Оставить отзыв о статье
Выгрузка на сайт завершилась с ошибками. import.xml: Произошла ошибка на стороне сервера. Получен неизвестный статус импорта.
Увидели такую ошибку и думаете «в коде кто-то накосячил»? А вот совсем не факт.
Об удивительной причине по которой обмен 1С с сайтом может неожиданно перестать работать я и хочу рассказать.
А началось все довольно безобидно. Позвонил старый клиент у которого уже года 2-3 работает магазин в связке с 1С и пожаловался что обмен перестал работать. Полез я к нему в 1С и вижу, что обмен действительно падает причем с разными ошибками и на разных файлах.
Первое что сделали — перешли на более мощный тариф хостинга. Половина зоопарка ошибок исчезла. Однако ошибка
Выгрузка на сайт завершилась с ошибками.
import.xml: Произошла ошибка на стороне сервера. Получен неизвестный статус импорта.
Неверный тип файла, либо превышен максимальный размер файлаНеверный тип файла, либо превышен максимальный размер файла
осталась и уходить не собиралась.
Пробовали выгружать и на тиражный магазин и на VDS на который другая 1С прекрасно все грузит — везде одна и та же ошибка.
В итоге обратились в поддержку Битрикса. Судя по оперативности и точности ответов поддержка знает о проблеме. А суть ответов была в следующем: поддержка вставила отладочную печать и попросила сделать выгрузку.
По результатам выгрузки в консоли 1С появилась отладочная информация вида
Array ( [name] => 04f5da44f3fe11e297cb002215a2039c_04f5da47f3fe11e297cb002215a2039c.jpg [size] => 3789 [tmp_name] => /home/i/mysite/public_html/upload/tmp/1ec/04f5da44f3fe11e297cb002215a2039c_04f5da47f3fe11e297cb002215a2039c.jpg [type] => application/octet-stream [COPY_FILE] => Y [description] => [copy] => 1 [MODULE_ID] => iblock )
Отсюда можно видеть, что одна из картинок имеет mimetype: application/octet-stream.
Далее по названию картинки вычисляем (например, можно в import.xml поискать по названию картинки) нехороший товар, пересохраняем его картинку в любом графическом редакторе и все работает.
Кому интересно — вся отладка заключается в изменении файла /bitrix/modules/main/classes/general/file.php:
после каждого вызова
return GetMessage("FILE_BAD_TYPE");
нужно вставить
Попросил поддержку исправить этот баг в импорте, но мы то с вами знаем сколько такие неважные исправления могут делаться. Поэтому я просто оставлю это сообщение здесь. Возможно кому-то поможет сэкономить время.
Назад в раздел