Ошибка папка backups недоступна для записи

  1. Offline

    snaiper

    Недавно здесь

    Регистрация:
    21.02.2008
    Сообщения:
    7
    Симпатии:
    0

    Здравствуйте господа!
    Короче проблема такая: при установке джумлы ни один из каталогов не доступен для записи. Ядро ставлю на локальный сервак (на других хостингах все было без замечаний). Думал гемор в правах доступа- поменял их аж на 0777, результат тот же. Тело что ставило сервак заверило меня что в настройках все гут. Вот сижу уже второй день и думаю в чем может быть проблема.%)
    Может кто то сталкивался с такой проблемой? Помогите тогда! (проблему в настройках вебсервера тоже не исключаю)
    Спасибо!

  2. Dead Krolik

    Offline

    Dead Krolik

    Недавно здесь
    => Cпециалист <=

    Регистрация:
    13.04.2007
    Сообщения:
    3 685
    Симпатии:
    101
    Пол:
    Мужской

    Ответ: Проблема! Ни один из каталогов не доступен для записи.

    >Думал гемор в правах доступа- поменял их аж на 0777, результат тот же
    Правильно думал. В правах и дело. Но ты уверен, что права правда поменялись?

  3. Offline

    snaiper

    Недавно здесь

    Регистрация:
    21.02.2008
    Сообщения:
    7
    Симпатии:
    0

    Ответ: Проблема! Ни один из каталогов не доступен для записи.

    Права менял через mc, проверял несколько раз- были изменены

  4. Dead Krolik

    Offline

    Dead Krolik

    Недавно здесь
    => Cпециалист <=

    Регистрация:
    13.04.2007
    Сообщения:
    3 685
    Симпатии:
    101
    Пол:
    Мужской

    Ответ: Проблема! Ни один из каталогов не доступен для записи.

    Стоп. А фраза «ни один из каталогов» — это какие например?

  5. Offline

    snaiper

    Недавно здесь

    Регистрация:
    21.02.2008
    Сообщения:
    7
    Симпатии:
    0

    Ответ: Проблема! Ни один из каталогов не доступен для записи.

    Права доступа на каталоги
    Для работы ВСЕХ функций и возможностей Joomla, ВСЕ указанные ниже каталоги должны быть доступны для записи:

    administrator/backups/ Недоступен для записи
    administrator/components/ Недоступен для записи
    administrator/modules/ Недоступен для записи
    administrator/templates/ Недоступен для записи
    components/ Недоступен для записи
    images/ Недоступен для записи
    images/banners/ Недоступен для записи
    images/stories/ Недоступен для записи
    language/ Недоступен для записи
    mambots/ Недоступен для записи
    mambots/content/ Недоступен для записи
    mambots/editors/ Недоступен для записи
    mambots/editors-xtd/ Недоступен для записи
    mambots/search/ Недоступен для записи
    mambots/system/ Недоступен для записи
    media/ Недоступен для записи
    modules/ Недоступен для записи
    templates/ Недоступен для записи
    Каталог кэша /usr/remad/www/gad_net/cache/ Недоступен для записи
    Каталог сессий /var/lib/php/session/ Доступен для записи

    На профессиональных хостингах такого гемора ни когда не было!

  6. chilly_bang

    Offline

    chilly_bang

    Недавно здесь
    => Cпециалист <=

    Регистрация:
    30.04.2006
    Сообщения:
    1 541
    Симпатии:
    38
    Пол:
    Мужской

    Ответ: Проблема! Ни один из каталогов не доступен для записи.

    так а ставить пытался? и что?

    чем проверял? как себя ведёт другая инсталляция на этом же сервере? другой инсталляционный пакет + другой браузер + другой комп?

  7. Offline

    snaiper

    Недавно здесь

    Регистрация:
    21.02.2008
    Сообщения:
    7
    Симпатии:
    0

    Ответ: Проблема! Ни один из каталогов не доступен для записи.

    На другом компе не проверял (сегодня проверю), с другим браузером таже хрень(опера), а работаю на 7м экспловере, про другие инсталяционные пакеты сказать не могу так как на серваке стоит только простенький биллинг. Он работает без замечаний.

    Добавлено через 2 минуты
    Может сервак попробывать перегрузить?

    Последнее редактирование: 22.02.2008

  8. Offline

    snaiper

    Недавно здесь

    Регистрация:
    21.02.2008
    Сообщения:
    7
    Симпатии:
    0

    Ответ: Проблема! Ни один из каталогов не доступен для записи.

    Народ, неужели ни кто не может чего нибудь дельного подсказать!

  9. tin

    Offline

    tin

    Недавно здесь

    Регистрация:
    22.11.2007
    Сообщения:
    126
    Симпатии:
    2
    Пол:
    Мужской

    Ответ: Проблема! Ни один из каталогов не доступен для записи.

    Да уш слишком расплывчето ты о серваке говориш

    Из выше изложенного проблема в нем ЕШЕ иногда такие приколы СПАНЕЛЬ делает но это редкость

    Да скорей всего сервак
    Ну или руки кривые

  10. Offline

    snaiper

    Недавно здесь

    Регистрация:
    21.02.2008
    Сообщения:
    7
    Симпатии:
    0

    Ответ: Проблема! Ни один из каталогов не доступен для записи.

    Я то же больше всего склоняюсь к тому что что проблема на сервере.
    Ну а руки у меня не кривые так как в установке сложного ну ни чего нет, скорее у того кто сервер ставил.

  11. tin

    Offline

    tin

    Недавно здесь

    Регистрация:
    22.11.2007
    Сообщения:
    126
    Симпатии:
    2
    Пол:
    Мужской

    Ответ: Проблема! Ни один из каталогов не доступен для записи.

    Хостера в топку

  12. Offline

    snaiper

    Недавно здесь

    Регистрация:
    21.02.2008
    Сообщения:
    7
    Симпатии:
    0

    Ответ: Проблема! Ни один из каталогов не доступен для записи.

    Хостер обещал переустановить apache, сказал что наверное в нем проблема. По результатам обязательно отпишусь.

  13. Dead Krolik

    Offline

    Dead Krolik

    Недавно здесь
    => Cпециалист <=

    Регистрация:
    13.04.2007
    Сообщения:
    3 685
    Симпатии:
    101
    Пол:
    Мужской

    Ответ: Проблема! Ни один из каталогов не доступен для записи.

    Да уж отпишись. Даже мне интересно стало.

  14. jenyav

    Offline

    jenyav

    Недавно здесь

    Регистрация:
    17.05.2008
    Сообщения:
    29
    Симпатии:
    0
    Пол:
    Мужской

    Ответ: Проблема! Ни один из каталогов не доступен для записи.

    спасибо за быстрый ответ, меняю на 777 а оно автоматически 755

Поделиться этой страницей

Viewing 15 replies — 1 through 15 (of 16 total)

  • Hi @exxis

    Please install and activate this helper plugin

    It should fix the problem. Let me know if it still does not work

    Best Regards

    Thread Starter
    exxis

    (@exxis)

    were do I have to put that file?

    • This reply was modified 2 years, 1 month ago by exxis.

    Hey @exxis

    You can zip it and install as any other plugin via Plugins > Add New > Upload

    Then activate it and that’s all.

    Let me know how it goes.

    Best Regards

    Any update on this @exxis ?

    What does the helper plugin do exactly @wp_media ?

    Will it be included in the next update?

    I am having the same issue, permissions are correct but getting the ‘directory is not writeable’ error message.

    • This reply was modified 2 years, 1 month ago by mespinozabta.

    Hi @mespinozabta,

    This helper plugin allows Imagify to better determine where the site root is for your WordPress installation on your server. In most cases, it should resolve this issue.

    In case you have any folders added to your Custom Folders section in your Imagify settings page, you would also need to ensure permissions and ownership are properly set for the following folder as well (this is where these images are backed up):

    [wordpress-root-location]/imagify-backup/

    I don’t believe this will be added in a future update as this is a relatively rare issue, but I can’t say either way for sure.

    If you’re still getting the same error after trying all of the above, you may want to contact your host to see if they can offer any input as to why Imagify is not being allowed to write images to these directories.

    Please let me know if you have any further questions on this and I’ll be more than happy to assist!

    Best regards

    @wp_media The plugin worked, thank you.

    Thread Starter
    exxis

    (@exxis)

    was using the helper plugin, however it somehow stopped working, I’m getting the same error message again.

    Hey @exxis

    ​Sorry to hear about that!

    I hope you checked with your host if anything changed on their end regarding permissions?

    Also, did you do any changes in terms of WP installation, moved it to another folder, or did anything that could be suspicious?

    What you can do is to activate this helper plugin and check its Info page. Can you tell me if there is any field with red background, especially in the first sections of the page where is the info about location and paths?

    Thanks!
    Marko

    Hi,
    I too have the same problem. Why don’t you integrate it in the Plugin core?
    I installed the “Imagify Custom Site Root” plugin and solved it but disabling it the problem comes back.
    Thanks

    Hello @sermatica,

    Thank you for your feedback on this!

    I can’t know for sure what decisions will be made in the future, but our team will certainly consider it as we move forward and try to improve Imagify!

    Hope you have a very nice rest of your day!

    Best regards,

    Hi,
    Yes, I’m getting the same error and after installing Imagify tool helper function able to see errors in RED which are below

    1) $_POST requests to https://stage.bradleysfish.com/wp-admin/admin-ajax.php blocked

    Request returned an error:

    cURL error 28: Operation timed out after 10000 milliseconds with 0 bytes

    2) $_POST requests to http://stage.bradleysfish.com/wp-cron.php blocked Request returned an error:

    cURL error 28: Operation timed out after 10001 milliseconds with 0 bytes

    Hi @snehaladdweb

    I am sorry to hear that.

    Those blocked requests may happen when there is a large request for optimization and lead your server to timeout. You will have to contact your host provider in order to unblock the requests and check if there is a firewall or security module that could block wp-cron.php self-request or if there is some limitation with wp-cron.

    Please let me know how it goes.

    Best regards,
    Ioanna

    Hi,

    Just came across this thread with a similar problem. This has occurred since my site was migrated to a new server. I then removed and reinstalled the backup plugin BackWPup but the same problem still persists. However, my new back up to drop box appears to be functioning OK, but I’m still getting the following error message on my wordpress dash:

    Your backup folder is NOT writable
    
    To correct this issue, make the folder writable.
    
    Your backup folder MIGHT be visible to the public
    
    To correct this issue, move the file from /home/dlila77qekrk/public_html/wp-content/plugins/wp-dbmanager/htaccess.txt to /.htaccess
    
    To correct this issue, move the file from /home/dlila77qekrk/public_html/wp-content/plugins/wp-dbmanager/index.php to /index.php
    
    Click here to let WP-DBManager try to fix it

    Hey @seabass888

    Thanks for your feedback!

    Just to be sure, you have a same problem with Imagify?

    As this is definitely related to the communication with server and it could happen with any plugin that has to make changes in uploads (or other) folder.

    Best Regards

    Thanks for the reply.

    No I don’t have the plugin Imagify. I was assuming my problem was specific to the plugin BackWPup. I’ve removed and then re-installed this plugin and have successfully created a new back up to Dropbox, however I still get this error message on my WP dashboard, and cannot remove. I’m a beginner wordpress developer, so no experience/knowledge. If I “Click here to let WP-DBManager try to fix it”. I get the following specific error text:
    “`Checking Security Status
    .htaccess is missing from

    index.php is missing from

    Checking Backup Status
    Checking Backup Folder () …
    Backup folder does NOT exist. Please create ‘backup-db’ folder in ‘/home/dlila77qekrk/public_html/wp-content’ folder and CHMOD it to ‘777’ or change the location of the backup folder under DB Option.

    Backup folder is NOT writable. Please CHMOD it to ‘777’.

    Checking MYSQL Dump Path (/usr/bin/mysqldump) …

    MYSQL dump path exists.

    Checking MYSQL Path (/usr/bin/mysql) …

    MYSQL path exists.

    Checking PHP Functions (passthru(), system() and exec()) …
    passthru() enabled.

    system() enabled.

    exec() enabled.

    Please Rectify The Error Highlighted In Red Before Proceeding On.

    Note: The checking of backup status is still undergoing testing, it may not be accurate.`

    I added the MYSQL Dump Path and the MYSQL Path – they had automated options to add. However the main error remains. Do i understand where I can add my new DB back up folder, and would have thought if i was backing up to Dropbox, why this is occurring? Please note this has problem has occured since my site was moved to a new server. I also fear I may have deleted a previous folder on my server when trying to remove the last back up and create a new one, but to be honest, I can’t specifically remember. Anyway, you can see the error message above. Please assist if possible. I guess the solution appears to be creating a new back up db folder in /home/dilila……etc.
    However, where do I create this? If this is the problem/solution? Thanks

  • Viewing 15 replies — 1 through 15 (of 16 total)

    Viewing 15 replies — 1 through 15 (of 16 total)

  • Hi @exxis

    Please install and activate this helper plugin

    It should fix the problem. Let me know if it still does not work

    Best Regards

    Thread Starter
    exxis

    (@exxis)

    were do I have to put that file?

    • This reply was modified 2 years, 1 month ago by exxis.

    Hey @exxis

    You can zip it and install as any other plugin via Plugins > Add New > Upload

    Then activate it and that’s all.

    Let me know how it goes.

    Best Regards

    Any update on this @exxis ?

    What does the helper plugin do exactly @wp_media ?

    Will it be included in the next update?

    I am having the same issue, permissions are correct but getting the ‘directory is not writeable’ error message.

    • This reply was modified 2 years, 1 month ago by mespinozabta.

    Hi @mespinozabta,

    This helper plugin allows Imagify to better determine where the site root is for your WordPress installation on your server. In most cases, it should resolve this issue.

    In case you have any folders added to your Custom Folders section in your Imagify settings page, you would also need to ensure permissions and ownership are properly set for the following folder as well (this is where these images are backed up):

    [wordpress-root-location]/imagify-backup/

    I don’t believe this will be added in a future update as this is a relatively rare issue, but I can’t say either way for sure.

    If you’re still getting the same error after trying all of the above, you may want to contact your host to see if they can offer any input as to why Imagify is not being allowed to write images to these directories.

    Please let me know if you have any further questions on this and I’ll be more than happy to assist!

    Best regards

    @wp_media The plugin worked, thank you.

    Thread Starter
    exxis

    (@exxis)

    was using the helper plugin, however it somehow stopped working, I’m getting the same error message again.

    Hey @exxis

    ​Sorry to hear about that!

    I hope you checked with your host if anything changed on their end regarding permissions?

    Also, did you do any changes in terms of WP installation, moved it to another folder, or did anything that could be suspicious?

    What you can do is to activate this helper plugin and check its Info page. Can you tell me if there is any field with red background, especially in the first sections of the page where is the info about location and paths?

    Thanks!
    Marko

    Hi,
    I too have the same problem. Why don’t you integrate it in the Plugin core?
    I installed the “Imagify Custom Site Root” plugin and solved it but disabling it the problem comes back.
    Thanks

    Hello @sermatica,

    Thank you for your feedback on this!

    I can’t know for sure what decisions will be made in the future, but our team will certainly consider it as we move forward and try to improve Imagify!

    Hope you have a very nice rest of your day!

    Best regards,

    Hi,
    Yes, I’m getting the same error and after installing Imagify tool helper function able to see errors in RED which are below

    1) $_POST requests to https://stage.bradleysfish.com/wp-admin/admin-ajax.php blocked

    Request returned an error:

    cURL error 28: Operation timed out after 10000 milliseconds with 0 bytes

    2) $_POST requests to http://stage.bradleysfish.com/wp-cron.php blocked Request returned an error:

    cURL error 28: Operation timed out after 10001 milliseconds with 0 bytes

    Hi @snehaladdweb

    I am sorry to hear that.

    Those blocked requests may happen when there is a large request for optimization and lead your server to timeout. You will have to contact your host provider in order to unblock the requests and check if there is a firewall or security module that could block wp-cron.php self-request or if there is some limitation with wp-cron.

    Please let me know how it goes.

    Best regards,
    Ioanna

    Hi,

    Just came across this thread with a similar problem. This has occurred since my site was migrated to a new server. I then removed and reinstalled the backup plugin BackWPup but the same problem still persists. However, my new back up to drop box appears to be functioning OK, but I’m still getting the following error message on my wordpress dash:

    Your backup folder is NOT writable
    
    To correct this issue, make the folder writable.
    
    Your backup folder MIGHT be visible to the public
    
    To correct this issue, move the file from /home/dlila77qekrk/public_html/wp-content/plugins/wp-dbmanager/htaccess.txt to /.htaccess
    
    To correct this issue, move the file from /home/dlila77qekrk/public_html/wp-content/plugins/wp-dbmanager/index.php to /index.php
    
    Click here to let WP-DBManager try to fix it

    Hey @seabass888

    Thanks for your feedback!

    Just to be sure, you have a same problem with Imagify?

    As this is definitely related to the communication with server and it could happen with any plugin that has to make changes in uploads (or other) folder.

    Best Regards

    Thanks for the reply.

    No I don’t have the plugin Imagify. I was assuming my problem was specific to the plugin BackWPup. I’ve removed and then re-installed this plugin and have successfully created a new back up to Dropbox, however I still get this error message on my WP dashboard, and cannot remove. I’m a beginner wordpress developer, so no experience/knowledge. If I “Click here to let WP-DBManager try to fix it”. I get the following specific error text:
    “`Checking Security Status
    .htaccess is missing from

    index.php is missing from

    Checking Backup Status
    Checking Backup Folder () …
    Backup folder does NOT exist. Please create ‘backup-db’ folder in ‘/home/dlila77qekrk/public_html/wp-content’ folder and CHMOD it to ‘777’ or change the location of the backup folder under DB Option.

    Backup folder is NOT writable. Please CHMOD it to ‘777’.

    Checking MYSQL Dump Path (/usr/bin/mysqldump) …

    MYSQL dump path exists.

    Checking MYSQL Path (/usr/bin/mysql) …

    MYSQL path exists.

    Checking PHP Functions (passthru(), system() and exec()) …
    passthru() enabled.

    system() enabled.

    exec() enabled.

    Please Rectify The Error Highlighted In Red Before Proceeding On.

    Note: The checking of backup status is still undergoing testing, it may not be accurate.`

    I added the MYSQL Dump Path and the MYSQL Path – they had automated options to add. However the main error remains. Do i understand where I can add my new DB back up folder, and would have thought if i was backing up to Dropbox, why this is occurring? Please note this has problem has occured since my site was moved to a new server. I also fear I may have deleted a previous folder on my server when trying to remove the last back up and create a new one, but to be honest, I can’t specifically remember. Anyway, you can see the error message above. Please assist if possible. I guess the solution appears to be creating a new back up db folder in /home/dilila……etc.
    However, where do I create this? If this is the problem/solution? Thanks

  • Viewing 15 replies — 1 through 15 (of 16 total)

     

    Пользователь 99060

    Заглянувший

    Сообщений: 38
    Баллов: 1
    Авторитет:

    0

    Рейтинг пользователя:

    0

    Регистрация: 19.08.2011

    #1

    0

    09.08.2012 16:14:00

    Здравствуйте коллеги!
    Вот уже несколько дней бьюсь с проблемой, как прикрутить виндовую шару к BitrixVM
    Поддержка в этом случае вообще практически не помогает, одни общие фразы.
    Поэтому обращаюсь к вам кто с этим сталкивался и может у кого что то получилось.
    Итак к делу:
    1. установил VMware player
    2. установил BitrixVM
    3. установил SAMBA, но она почему-то оказалась без нужного пакета для монтирования дисков!
    4. установил пакет cifs-utils-5.6
    Далее начал монтировать диски.
    5. Создал точку монтирования (тупо создал папку) /mnt/sunlion/
    Наши сетевые диски видны у меня в проводнике, у системного администратора взял адрес и у меня получилось вот такое выражение:

    Код
     mount.cifs 'sunlion.rudfs' /mnt/sunlion --verbose -o iocharset=utf8,codepage=cp866,user=user_name,password=password_user

    После монтирования у меня в вышеупомянутой папке показались две папки, которые есть на этой шаре

    /mnt/sunlion/public
    /mnt/sunlion/music

    однако при попытке войти в них вылетает ошибка вида:

    Нет такого файла или папки.
    Error code: 2
    Error message from server: No such file
    Request code: 11


    И конечно же в папках ни чего нет! Следовательно что то прошло не правильно! Вопрос что?

     

    Администратор

    Сообщений: 1193
    Баллов: 238
    Авторитет:

    1

    Рейтинг пользователя:

    7

    Регистрация: 20.12.2006

    Попробуйте указывать полный адрес sunlion.rudfspublic

     

    Пользователь 99060

    Заглянувший

    Сообщений: 38
    Баллов: 1
    Авторитет:

    0

    Рейтинг пользователя:

    0

    Регистрация: 19.08.2011

    #3

    0

    09.08.2012 17:45:59

    Код
    Попробуйте указывать полный адрес sunlion.rudfspublic
     

    Пробовал, в этом случае папки не создаются а в консоли ошибка вида:

    Код
    [root@localhost /]# mount.cifs 'sunlion.rudfspublic' /mnt/sunlion --verbose -o iocharset=utf8,codepage=cp866,user=..потерто..,password=..потерто
    ..,domen=sunlion.ru
    mount.cifs kernel mount options: ip=192.168.15.14,unc=sunlion.rudfs,iocharset=utf8,codepage=cp866,user=bruev.v,,domain=sunlion.ru,prefixpath=public,pass=********
    mount error(11): Resource temporarily unavailable
    Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
     
     

    Пользователь 99060

    Заглянувший

    Сообщений: 38
    Баллов: 1
    Авторитет:

    0

    Рейтинг пользователя:

    0

    Регистрация: 19.08.2011

    #4

    0

    13.08.2012 18:00:08

    Задачка решена! Диск удалось примонтировать! Проблема пряталась в dfs

    (Distributed File System)

    Если диск подключен через dfs, то монтировать его нужно все равно напрямую минуя эту самую dfs. В моем случае это выглядело так:
    Было:  

    Код
    'sunlion.rudfs'
    

    Стало:

    Код
    '2.168.15.14public$' 

    И шара и папки стали сразу видны в проводнике SSH

    Может кому и пригодится мой опыт!
    Всем спасибо и удачи!

     

    Пользователь 89296

    Постоянный посетитель

    Сообщений: 115
    Баллов: 11
    Авторитет:

    1

    Рейтинг пользователя:

    0

    Регистрация: 25.04.2011

    #5

    0

    23.08.2013 22:34:46

    А у меня другая проблема. Диск монтируется в папку легко командой:

    Код
    mount -t cifs -o ro,iocharset=utf8,nounix,codepage=cp866,username=fs_bitrix,password=??? //tra-ta-ta.ru/bitrix$ /home/bitrix/www/fileserver

    Пробовал различные ее варианты. Предварительно само собой надо установить cifs-utils

    Код
    yum -y install cifs-utils

    В итоге имею абсолютно работающую по SSH и через mc папку. Но битрикс упрямо считает ее обычным файлом.
    После того как отмонтируешь — файл обратно «превращается» в битриксовом файлменеджере в папку.

    Пробовал и симлинки делать на эту папку — они вместе с ней испытывают эти чудесные превращения. Может кто сталкивался и подскажет решение?
    Самое обидное, что сегодня утром все работало нормально. Просто папка была примонтирована под рутом и битрикс не мог туда писать. Я ее отмонтировал и обратно вернуть ничего уже не получилось. Даже как было:(

     

    Пользователь 3954

    Администратор

    Сообщений: 2072
    Баллов: 290
    Авторитет:

    0

    Рейтинг пользователя:

    18

    Регистрация: 28.03.2006

    Используйте опцию монтирования noserverino.

    https://bugs.php.net/bug.php?id=51266

     

    Пользователь 233759

    Заглянувший

    Сообщений: 6
    Авторитет:

    1

    Рейтинг пользователя:

    0

    Регистрация: 27.12.2013

    У меня другая проблема. Установил cifs-utils:
    yum -y install cifs-utils

    Примонтировал хранилище:
    mount.cifs //192.168.18.73/3dd_webdav /home/bitrix/www/docs/folder/files —verbose -o rw,iocharset=utf8,nounix,codepage=cp866,fmode=0777,noserverino,user=********@****.net,password=********

    Из консоли линукса под рутом могу и читать и записывать. А вот с битрикса не получается никак. Думал примонтировать под пользователем Bitrix, но система не даёт, пишет: This program is not installed setuid root —  «user» CIFS mounts not supported.

     

    Пользователь 233759

    Заглянувший

    Сообщений: 6
    Авторитет:

    1

    Рейтинг пользователя:

    0

    Регистрация: 27.12.2013

    #8

    0

    27.12.2013 15:19:08

    Решил проблему сам, нужно было добавить ещё такие опции монтирования: uid=bitrix и gid=bitrix

    Мало ли кому пригодится, полная команда для монтирования cifs в BitrixVM выглядит так:

    Код
    mount.cifs //192.168.18.73/3dd_webdav /home/bitrix/www/docs/cliniccases/files --verbose -o rw,iocharset=utf8,nounix,codepage=cp866,fmode=0777,noserverino,uid=bitrix,gid=bitrix,user=********@****.net,password=********
     

    Пользователь 192990

    Заглянувший

    Сообщений: 46
    Баллов: 2
    Авторитет:

    1

    Рейтинг пользователя:

    0

    Регистрация: 31.10.2013

    #9

    0

    06.02.2015 16:17:15

    Цитата
    Михаил Устименко написал:
    Решил проблему сам, нужно было добавить ещё такие опции монтирования: uid=bitrix и gid=bitrix

    Мало ли кому пригодится, полная команда для монтирования cifs в BitrixVM выглядит так:

    Код
     mount.cifs //192.168.18.73/3dd_webdav /home/bitrix/www/docs/cliniccases/files --verbose -o rw,iocharset=utf8,nounix,codepage=cp866,fmode=0777,noserverino,uid=bitrix,gid=bitrix,user=********@****.net,password=******** 

    Все права даны на пользователя apache. Когда монтируется папка этой командой, она всё равно не видна из битрикса как папка.
    Есть разница в правах(как дать на группу и выполнение все права?):
     

     

    Пользователь 192990

    Заглянувший

    Сообщений: 46
    Баллов: 2
    Авторитет:

    1

    Рейтинг пользователя:

    0

    Регистрация: 31.10.2013

    #10

    0

    06.02.2015 16:53:25

    То есть, по сути, не смотря на права 0777 ставятся 0755

     

    Пользователь 192990

    Заглянувший

    Сообщений: 46
    Баллов: 2
    Авторитет:

    1

    Рейтинг пользователя:

    0

    Регистрация: 31.10.2013

    #11

    0

    06.02.2015 17:09:12

    Сделал полные права, но бекап битрикса всё равно отказывается туда создаваться:

    Ошибка
    Папка /var/www/html/bitrix/backup недоступна на запись

    Почему появляется ошибка?

    Это классическая ошибка прав доступа к файлам и папкам.

    Она заключается в том, что сайт не может получить доступ (чтение и/или запись) у указанным файлам и папкам.

    Обычно, это происходит вследствие того, что указанные файлы были созданы от имени другого пользователя системы (не путать с пользователями Битрикс). Это может быть как в прямом случае (пользователь вошел через FTP, SSH или файл-менеджер на хостинге и создал файл от своего имени), так и в косвенном — обычно это бывает, когда выполнение агентов настроено на крон, а запуск задачи крона выполняется от имени root — в таких случаях, если агенты создают какие-то временные файлы или файлы кеша — эти файлы не смогут быть перезаписаны при обычной работе сайта.

    На что эта ошибка влияет?

    Данная проблема приводит в ошибкам при работе с файлами.

    Например, если страница (файл) публичной части недоступна для записи, то невозможно будет редактирование этой страницы средствами Битрикс — это будет приводить к ошибке: «Ошибка при сохранении файла скрипта. Изменения не сохранены».

    Как исправить ошибку?

    Чтобы исправить ошибку, нужно изменить права доступа каждого файла/папки — поочередно, либо сразу на весь сайт (это можно сделать командой через SSH-подключение). При этом необходимо помнить, что права должны быть не 777, а те, которые указаны в /bitrix/php_interface/dbconn.php — обычно 644 для файлов и 755 для папок.

    Требуется наша помощь?

    Мы имеем огромный опыт, на протяжении 10 лет помогая клиентам в решении самых различных проблем на их сайтах.

    Поэтому, если Вы не имеете возможности решить эту проблему самостоятельно, обращайтесь к нам — мы все сделаем оперативно и квалифицированно.

    Какие права на папки стоят у вас?

    777
    755
    644
    Не знаю
    Все равно
    А что это?

    0 Пользователей и 1 Гость просматривают эту тему.

    • 15 Ответов
    • 13256 Просмотров

    Никогда не сталкивался проблемами на папки, но не чистая свела один проект на Joomla с хостингом freehost… и началось  !. дай бог здоровья тем кто сконфигурировал им сервера.
    традиционно на всех хостингах в информация о системе — Права на папки  стояли права 755 на папки. в случае с фрихост 755 но все папки с ними следующие:

    administrator/backups/	Недоступен на запись
    administrator/components/ Недоступен на запись
    administrator/language/ Недоступен на запись
    administrator/language/en-GB/ Недоступен на запись
    administrator/language/ru-RU/ Недоступен на запись
    administrator/modules/ Недоступен на запись
    administrator/templates/ Недоступен на запись
    components/ Недоступен на запись
    images/ Недоступен на запись
    images/banners/ Недоступен на запись
    images/stories/ Недоступен на запись
    language/ Недоступен на запись
    language/en-GB/ Недоступен на запись
    language/pdf_fonts/ Недоступен на запись
    language/ru-RU/ Недоступен на запись
    media/ Недоступен на запись
    modules/ Недоступен на запись
    plugins/ Недоступен на запись
    plugins/content/ Недоступен на запись
    plugins/editors/ Недоступен на запись
    plugins/editors-xtd/ Недоступен на запись
    plugins/search/ Недоступен на запись
    plugins/system/ Недоступен на запись
    plugins/user/ Недоступен на запись
    plugins/xmlrpc/ Недоступен на запись
    templates/ Недоступен на запись

    Естественно что либо поставить / удалить / изменить невозможно.
    Написал в сапорт, ответили что Joomla требует 777. И других вариантов просто нет. (стеб какой-то) отправили читать литературу. Может и надо конечно, но почему тогда на всех хостингах 755 работает, на их хостинге на другом аккаунте работает, а тут нет. Хотя на другом же их сервере все работает отлично с 755 правами. тут же по их словам только 777.
    Просьба проверить конфигурации php в рамках пользователя на сервере была напрочь проигнорирована.
    в общем все лирика, но насколько будет корректно (безопасно) выставить 777 ? или может кто сталкивался с такими проблемами у этого или других хостеров?

    уважаемый 4webspot (Support Team) в этой теме пишет актуально и верно:

    при условии выполнений техтребований по установке и безопасности системы Joomla папки должны иметь права 755, файлы — 644 и configuration.php — 444.

    ставьте права 777 на свой собственный страх и риск.

    может что поменялось?
    J 1.5.22

    Я с таким приколом тоже сталкивался — был безопасный режим включен.
    У меня 750

    Записан

    Создание сайтов, шаблонов, помощь в решении проблем.

    scs, это значит, что на сервере работает php как модуль апач, при этом используется обычный апач, без mpm-itk патча, т.е. веб сервер работает от пользователя nobody, от сюда и необходимость выставления прав =777 на каталоги, в которые необходимо писать и =666, на файлы, в которые необходимо писать.

    Я с таким приколом тоже сталкивался — был безопасный режим включен.
    У меня 750

    безопасный режим выключен

    scs, это значит, что на сервере работает php как модуль апач, при этом используется обычный апач, без mpm-itk патча, т.е. веб сервер работает от пользователя nobody, от сюда и необходимость выставления прав =777 на каталоги, в которые необходимо писать и =666, на файлы, в которые необходимо писать.

    насколько это корректно?

    насколько это корректно?

    В плане безопасности, не очень.

    В плане безопасности, не очень.

    как это выглядит на практике?

    как это выглядит на практике?

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

    на вопрос как работает апач ответ не дали
    возможно ли сделать с правами 755 — ответа не последовал.
    на вопрос кто владелец папки — «PHP работает от другого владельца.»
    на просьбу помочь разобраться — ответа просто не было и молчание.на вопрос — делаем выводы.
    что делать то а? валить на другой акаунт или переехать? проект только начат. но перспектива по целевому региона есть.

    что делать то а? валить на другой акаунт или переехать? проект только начат. но перспектива по целевому региона есть.

    Тут решать только Вам.

    да… Оказывается есть ещё много хостингов где так и не поняли как нужно настраивать сервер для Joomla…
    Я, к счастью, с такими хостингами не сталкивался…

    Записан

    Я с мобильного, в основном…

    да… Оказывается есть ещё много хостингов где так и не поняли как нужно настраивать сервер для Joomla…
    Я, к счастью, с такими хостингами не сталкивался…

    даже gzip включить нельзя ни через панель ни через .htaccess

    на хостлайф походу такая же песня, причем вроде был выключен безопасный режим, а тут РАААЗ  — админы походу решили поиграться и включили SAFE — и все… причем все, что МОЖНО, перевыставлено на 777 (!), а толку — 0
    или обновились криворуко, PHP 5.2.17, дата билда НАПИСАНА — 27мая2011 )))

    « Последнее редактирование: 28.05.2011, 13:21:27 от sergoguga »

    Записан

    >>> Верстка 100 евро — ждешь новый курс? Пиши!
    >>> Создание моб. приложений по ГОСТу)))! Личка работает!
    >>> Микроразметка по стандартам — цены адекват! Пиши, не боись!
    >>> Личный кабинет на ZOO — уже сделан! Пиши в личку, не стесняйся!

    Написал в сапорт, ответили что Joomla требует 777

    Это бред.

    Надо узнать у хостера под каким пользователем и группой работает apache, а также посмотреть какие права и владелец у Вас стоят в директории сайта. Как правило достаточно 750 или 770.

    тогда подскажите какие папки необходимо поставить права 777, что бы можно было сделать бэкап и установить ну что б полноценно работать

    Ого, столько времени прошло, а ничего не поменялось.
    Я в данный момент с freehost маюсь — не дает права на запись папок tmp и log.
    При этом права 777 я поставил и safe_mode выключен.

    Исправить Невозможно создать каталог wp-content / uploads Ошибка WordPress

    Я только что перенес свои данные WordPress на новый сервер. После этого я не могу загрузить ни один медиафайл.

    На панели управления отображается сообщение об ошибке «Папка загрузки недоступна для записи. Функции экспорта и загрузки файлов не будут работать».

    • Готов поспорить, что безопасный режим включен на сервере, на который вы только что перешли.

    Вам необходимо обновить разрешения для каталога загрузки.

    если у вас есть доступ по ssh, что-то вроде chmod a+w wp-content/uploads или если вы используете какой-либо FTP-клиент, попробуйте щелкнуть правой кнопкой мыши по папке и установить group или all разрешение на запись.

    Если вы не знаете, где находится ваша папка с загрузками, вы можете проверить wp-config.php для этой линии define( 'UPLOADS', YOUR UPLOAD FOLDER HERE);

    • Я столько раз обновлял разное количество. Подскажите точное количество и папку. Я попытался внести изменения в папку ЗАГРУЗКИ, 2014/09 и index.php
    • Вероятно, у вас по умолчанию wp-content/uploads/, но вы можете проверить, отметившись wp-config.php для чего-то вроде define( 'UPLOADS', YOUR UPLOAD FOLDER HERE);.

    Зависит от вашего окружения. Узнайте, какой пользователь использует wordpress, и запустите следующее:

    chown -R user:group /root/of/install/wp-content/uploads chmod -R 755 /root/of/install/wp-content/uploads 

    замените ‘user’ на пользователя, от имени которого запускается wp, и сделайте то же самое для ‘group’, убедитесь, что приложение ftp, которое вы используете, запускается от имени того же пользователя, что и ‘user’ выше

    если вы не заботитесь о безопасности, вы можете просто запустить

    chmod -R 777 /root/of/install/wp-content/uploads 

    HTH

    У меня возникла эта проблема после переноса сайта на новый сервер.

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

    Проблема в том, что иногда WordPress заполнит опцию под названием upload_path в wp_options Таблица. Очень похоже на комментарий выше с PHP Define: 'UPLOADS' это может быть установлено в вашем wp-config.php это не идеально, так как жестко кодирует ваши пути.

    Так что исправить довольно просто, вам нужно Чисто (как в случае удаления) либо ключ из wp_options table или просто значение этого ключа.

    Как это сделать? Внутри WordPress есть удобный способ сделать это: (осторожно: будьте осторожны, чтобы не изменять никакие другие поля на следующих шагах, кроме того, которое вы ищете).

    1. Войдите в свой WP Admin
    2. Перейдите по этому URL-адресу на своем сайте: /wp-admin/options.php. Это предоставит вам полный список параметров WP в вашем wp_options таблица базы данных.
    3. Найдите (Ctrl + F) следующее название опции: upload_path
    4. Если у него есть значение, просто удалите то, что находится в этом поле.
    5. Больше ничего не меняйте и нажмите Save Changes внизу

    Затем WordPress начнет использовать путь по умолчанию (/wp-content/uploads/) в папку загрузок

    Папка загрузки была недоступна для записи. Путь загрузки нужно было удалить в базе данных> таблица wp_options.

    • 1, возможно, вы захотите сделать этот ответ более подробным, чтобы прояснить, как, по вашему мнению, параграфы должны решить проблему.

    Я решил эту проблему, выполнив следующие действия:

    1. Откройте myphpadmin через cpanel и откройте свою базу данных.

    2. Выбрать таблицу опций

    3. Найдите строку с именем upload_url и нажмите изменить.

    4. Удалите значение и нажмите «Сохранить».

    Tweet

    Share

    Link

    Plus

    Send

    Send

    Pin

    Ошибка при попытке загрузить изображение в Symphony

    Папка назначения недоступна для записи. Пожалуйста, проверьте разрешения на
    / рабочее пространство / изображения / х

    Я изменил владельца каталога «x» на apache: apache, даже дал ему 777 и все еще получаю ошибку.

    Веб-сайт был создан и протестирован в VM, и мы смогли загрузить другие изображения в том же разделе, прежде чем переходить на живую версию. Я попытался загрузить то же самое изображение на 120 КБ, которое работало прежде.

    РЕДАКТИРОВАТЬ:
    Подобное происходит, если я пытаюсь создать страницу с Blueprints> Pages
    я получил

    Шаблон страницы не может быть записан на диск. Пожалуйста, проверьте разрешения
    на / рабочая область / страницы

    Кроме того, при входе в систему я получаю сообщение

    Файл конфигурации Symphony, /manifest/config.php, недоступен для записи

    Все эти файлы принадлежат Apache и имеют 664 и 775 каталогов

    Symphony был установлен путем сохранения sql из phpmyadmin локальной установки Symphony и импорта его в базу данных живого сервера; затем запустить / установить

    1

    Решение

    Другие решения

    1. Проверьте, что пользователь работает с PHP (apache?) также имеет разрешения для перехода в каждый из каталогов выше каталога ‘x’: images, workspace, так далее.
    2. Убедитесь, что в каталоге ‘x’ нет списков ACL, которые мешают записи соответствующим пользователем.
    3. Посмотрите в SELinux, если он включен. (У меня нет ничего, чтобы предложить по этому вопросу, но, очевидно, это может помешать записи в каталоги, которые были перенесены откуда-то еще.

    0


    1. snaiper

      Offline

      snaiper

      Недавно здесь

      Регистрация:
      21.02.2008
      Сообщения:
      7
      Симпатии:
      0

      Здравствуйте господа!
      Короче проблема такая: при установке джумлы ни один из каталогов не доступен для записи. Ядро ставлю на локальный сервак (на других хостингах все было без замечаний). Думал гемор в правах доступа- поменял их аж на 0777, результат тот же. Тело что ставило сервак заверило меня что в настройках все гут. Вот сижу уже второй день и думаю в чем может быть проблема.%)
      Может кто то сталкивался с такой проблемой? Помогите тогда! (проблему в настройках вебсервера тоже не исключаю)
      Спасибо!

    2. Dead Krolik

      Offline

      Dead Krolik

      Недавно здесь
      => Cпециалист <=

      Регистрация:
      13.04.2007
      Сообщения:
      3 685
      Симпатии:
      101
      Пол:
      Мужской

      Ответ: Проблема! Ни один из каталогов не доступен для записи.

      >Думал гемор в правах доступа- поменял их аж на 0777, результат тот же
      Правильно думал. В правах и дело. Но ты уверен, что права правда поменялись?


    3. snaiper

      Offline

      snaiper

      Недавно здесь

      Регистрация:
      21.02.2008
      Сообщения:
      7
      Симпатии:
      0

      Ответ: Проблема! Ни один из каталогов не доступен для записи.

      Права менял через mc, проверял несколько раз- были изменены

    4. Dead Krolik

      Offline

      Dead Krolik

      Недавно здесь
      => Cпециалист <=

      Регистрация:
      13.04.2007
      Сообщения:
      3 685
      Симпатии:
      101
      Пол:
      Мужской

      Ответ: Проблема! Ни один из каталогов не доступен для записи.

      Стоп. А фраза «ни один из каталогов» — это какие например?


    5. snaiper

      Offline

      snaiper

      Недавно здесь

      Регистрация:
      21.02.2008
      Сообщения:
      7
      Симпатии:
      0

      Ответ: Проблема! Ни один из каталогов не доступен для записи.

      Права доступа на каталоги
      Для работы ВСЕХ функций и возможностей Joomla, ВСЕ указанные ниже каталоги должны быть доступны для записи:

      administrator/backups/ Недоступен для записи
      administrator/components/ Недоступен для записи
      administrator/modules/ Недоступен для записи
      administrator/templates/ Недоступен для записи
      components/ Недоступен для записи
      images/ Недоступен для записи
      images/banners/ Недоступен для записи
      images/stories/ Недоступен для записи
      language/ Недоступен для записи
      mambots/ Недоступен для записи
      mambots/content/ Недоступен для записи
      mambots/editors/ Недоступен для записи
      mambots/editors-xtd/ Недоступен для записи
      mambots/search/ Недоступен для записи
      mambots/system/ Недоступен для записи
      media/ Недоступен для записи
      modules/ Недоступен для записи
      templates/ Недоступен для записи
      Каталог кэша /usr/remad/www/gad_net/cache/ Недоступен для записи
      Каталог сессий /var/lib/php/session/ Доступен для записи

      На профессиональных хостингах такого гемора ни когда не было!

    6. chilly_bang

      Offline

      chilly_bang

      Недавно здесь
      => Cпециалист <=

      Регистрация:
      30.04.2006
      Сообщения:
      1 541
      Симпатии:
      38
      Пол:
      Мужской

      Ответ: Проблема! Ни один из каталогов не доступен для записи.

      так а ставить пытался? и что?

      чем проверял? как себя ведёт другая инсталляция на этом же сервере? другой инсталляционный пакет + другой браузер + другой комп?


    7. snaiper

      Offline

      snaiper

      Недавно здесь

      Регистрация:
      21.02.2008
      Сообщения:
      7
      Симпатии:
      0

      Ответ: Проблема! Ни один из каталогов не доступен для записи.

      На другом компе не проверял (сегодня проверю), с другим браузером таже хрень(опера), а работаю на 7м экспловере, про другие инсталяционные пакеты сказать не могу так как на серваке стоит только простенький биллинг. Он работает без замечаний.

      Добавлено через 2 минуты
      Может сервак попробывать перегрузить?

      Последнее редактирование: 22.02.2008


    8. snaiper

      Offline

      snaiper

      Недавно здесь

      Регистрация:
      21.02.2008
      Сообщения:
      7
      Симпатии:
      0

      Ответ: Проблема! Ни один из каталогов не доступен для записи.

      Народ, неужели ни кто не может чего нибудь дельного подсказать!

    9. tin

      Offline

      tin

      Недавно здесь

      Регистрация:
      22.11.2007
      Сообщения:
      126
      Симпатии:
      2
      Пол:
      Мужской

      Ответ: Проблема! Ни один из каталогов не доступен для записи.

      Да уш слишком расплывчето ты о серваке говориш

      Из выше изложенного проблема в нем ЕШЕ иногда такие приколы СПАНЕЛЬ делает но это редкость

      Да скорей всего сервак
      Ну или руки кривые


    10. snaiper

      Offline

      snaiper

      Недавно здесь

      Регистрация:
      21.02.2008
      Сообщения:
      7
      Симпатии:
      0

      Ответ: Проблема! Ни один из каталогов не доступен для записи.

      Я то же больше всего склоняюсь к тому что что проблема на сервере.
      Ну а руки у меня не кривые так как в установке сложного ну ни чего нет, скорее у того кто сервер ставил.

    11. tin

      Offline

      tin

      Недавно здесь

      Регистрация:
      22.11.2007
      Сообщения:
      126
      Симпатии:
      2
      Пол:
      Мужской

      Ответ: Проблема! Ни один из каталогов не доступен для записи.

      Хостера в топку


    12. snaiper

      Offline

      snaiper

      Недавно здесь

      Регистрация:
      21.02.2008
      Сообщения:
      7
      Симпатии:
      0

      Ответ: Проблема! Ни один из каталогов не доступен для записи.

      Хостер обещал переустановить apache, сказал что наверное в нем проблема. По результатам обязательно отпишусь.

    13. Dead Krolik

      Offline

      Dead Krolik

      Недавно здесь
      => Cпециалист <=

      Регистрация:
      13.04.2007
      Сообщения:
      3 685
      Симпатии:
      101
      Пол:
      Мужской

      Ответ: Проблема! Ни один из каталогов не доступен для записи.

      Да уж отпишись. Даже мне интересно стало.

    14. jenyav

      Offline

      jenyav

      Недавно здесь

      Регистрация:
      17.05.2008
      Сообщения:
      29
      Симпатии:
      0
      Пол:
      Мужской

      Ответ: Проблема! Ни один из каталогов не доступен для записи.

      спасибо за быстрый ответ, меняю на 777 а оно автоматически 755

    Поделиться этой страницей


    Форумы Joomla! CMS

    Какие права на папки стоят у вас?

    777
    755
    644
    Не знаю
    Все равно
    А что это?

    0 Пользователей и 1 Гость просматривают эту тему.

    • 15 Ответов
    • 13306 Просмотров

    Никогда не сталкивался проблемами на папки, но не чистая свела один проект на Joomla с хостингом freehost… и началось  !. дай бог здоровья тем кто сконфигурировал им сервера.
    традиционно на всех хостингах в информация о системе — Права на папки  стояли права 755 на папки. в случае с фрихост 755 но все папки с ними следующие:

    administrator/backups/	Недоступен на запись
    administrator/components/ Недоступен на запись
    administrator/language/ Недоступен на запись
    administrator/language/en-GB/ Недоступен на запись
    administrator/language/ru-RU/ Недоступен на запись
    administrator/modules/ Недоступен на запись
    administrator/templates/ Недоступен на запись
    components/ Недоступен на запись
    images/ Недоступен на запись
    images/banners/ Недоступен на запись
    images/stories/ Недоступен на запись
    language/ Недоступен на запись
    language/en-GB/ Недоступен на запись
    language/pdf_fonts/ Недоступен на запись
    language/ru-RU/ Недоступен на запись
    media/ Недоступен на запись
    modules/ Недоступен на запись
    plugins/ Недоступен на запись
    plugins/content/ Недоступен на запись
    plugins/editors/ Недоступен на запись
    plugins/editors-xtd/ Недоступен на запись
    plugins/search/ Недоступен на запись
    plugins/system/ Недоступен на запись
    plugins/user/ Недоступен на запись
    plugins/xmlrpc/ Недоступен на запись
    templates/ Недоступен на запись

    Естественно что либо поставить / удалить / изменить невозможно.
    Написал в сапорт, ответили что Joomla требует 777. И других вариантов просто нет. (стеб какой-то) отправили читать литературу. Может и надо конечно, но почему тогда на всех хостингах 755 работает, на их хостинге на другом аккаунте работает, а тут нет. Хотя на другом же их сервере все работает отлично с 755 правами. тут же по их словам только 777.
    Просьба проверить конфигурации php в рамках пользователя на сервере была напрочь проигнорирована.
    в общем все лирика, но насколько будет корректно (безопасно) выставить 777 ? или может кто сталкивался с такими проблемами у этого или других хостеров?

    уважаемый 4webspot (Support Team) в этой теме пишет актуально и верно:

    при условии выполнений техтребований по установке и безопасности системы Joomla папки должны иметь права 755, файлы — 644 и configuration.php — 444.

    ставьте права 777 на свой собственный страх и риск.

    может что поменялось?
    J 1.5.22

    Я с таким приколом тоже сталкивался — был безопасный режим включен.
    У меня 750

    Записан

    Создание сайтов, шаблонов, помощь в решении проблем.

    scs, это значит, что на сервере работает php как модуль апач, при этом используется обычный апач, без mpm-itk патча, т.е. веб сервер работает от пользователя nobody, от сюда и необходимость выставления прав =777 на каталоги, в которые необходимо писать и =666, на файлы, в которые необходимо писать.

    Я с таким приколом тоже сталкивался — был безопасный режим включен.
    У меня 750

    безопасный режим выключен

    scs, это значит, что на сервере работает php как модуль апач, при этом используется обычный апач, без mpm-itk патча, т.е. веб сервер работает от пользователя nobody, от сюда и необходимость выставления прав =777 на каталоги, в которые необходимо писать и =666, на файлы, в которые необходимо писать.

    насколько это корректно?

    насколько это корректно?

    В плане безопасности, не очень.

    В плане безопасности, не очень.

    как это выглядит на практике?

    как это выглядит на практике?

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

    на вопрос как работает апач ответ не дали
    возможно ли сделать с правами 755 — ответа не последовал.
    на вопрос кто владелец папки — «PHP работает от другого владельца.»
    на просьбу помочь разобраться — ответа просто не было и молчание.на вопрос — делаем выводы.
    что делать то а? валить на другой акаунт или переехать? проект только начат. но перспектива по целевому региона есть.

    что делать то а? валить на другой акаунт или переехать? проект только начат. но перспектива по целевому региона есть.

    Тут решать только Вам.

    да… Оказывается есть ещё много хостингов где так и не поняли как нужно настраивать сервер для Joomla…
    Я, к счастью, с такими хостингами не сталкивался…

    Записан

    Я с мобильного, в основном…

    да… Оказывается есть ещё много хостингов где так и не поняли как нужно настраивать сервер для Joomla…
    Я, к счастью, с такими хостингами не сталкивался…

    даже gzip включить нельзя ни через панель ни через .htaccess

    на хостлайф походу такая же песня, причем вроде был выключен безопасный режим, а тут РАААЗ  — админы походу решили поиграться и включили SAFE — и все… причем все, что МОЖНО, перевыставлено на 777 (!), а толку — 0
    или обновились криворуко, PHP 5.2.17, дата билда НАПИСАНА — 27мая2011 )))

    « Последнее редактирование: 28.05.2011, 13:21:27 от sergoguga »

    Записан

    >>> Верстка 100 евро — ждешь новый курс? Пиши!
    >>> Создание моб. приложений по ГОСТу)))! Личка работает!
    >>> Микроразметка по стандартам — цены адекват! Пиши, не боись!
    >>> Личный кабинет на ZOO — уже сделан! Пиши в личку, не стесняйся!

    Написал в сапорт, ответили что Joomla требует 777

    Это бред.

    Надо узнать у хостера под каким пользователем и группой работает apache, а также посмотреть какие права и владелец у Вас стоят в директории сайта. Как правило достаточно 750 или 770.

    тогда подскажите какие папки необходимо поставить права 777, что бы можно было сделать бэкап и установить ну что б полноценно работать

    Ого, столько времени прошло, а ничего не поменялось.
    Я в данный момент с freehost маюсь — не дает права на запись папок tmp и log.
    При этом права 777 я поставил и safe_mode выключен.

    Viewing 15 replies — 1 through 15 (of 16 total)

  • Hi @exxis

    Please install and activate this helper plugin

    It should fix the problem. Let me know if it still does not work

    Best Regards

    Thread Starter
    exxis

    (@exxis)

    were do I have to put that file?

    • This reply was modified 2 years, 6 months ago by exxis.

    Hey @exxis

    You can zip it and install as any other plugin via Plugins > Add New > Upload

    Then activate it and that’s all.

    Let me know how it goes.

    Best Regards

    Any update on this @exxis ?

    What does the helper plugin do exactly @wp_media ?

    Will it be included in the next update?

    I am having the same issue, permissions are correct but getting the ‘directory is not writeable’ error message.

    • This reply was modified 2 years, 5 months ago by mespinozabta.

    Hi @mespinozabta,

    This helper plugin allows Imagify to better determine where the site root is for your WordPress installation on your server. In most cases, it should resolve this issue.

    In case you have any folders added to your Custom Folders section in your Imagify settings page, you would also need to ensure permissions and ownership are properly set for the following folder as well (this is where these images are backed up):

    [wordpress-root-location]/imagify-backup/

    I don’t believe this will be added in a future update as this is a relatively rare issue, but I can’t say either way for sure.

    If you’re still getting the same error after trying all of the above, you may want to contact your host to see if they can offer any input as to why Imagify is not being allowed to write images to these directories.

    Please let me know if you have any further questions on this and I’ll be more than happy to assist!

    Best regards

    @wp_media The plugin worked, thank you.

    Thread Starter
    exxis

    (@exxis)

    was using the helper plugin, however it somehow stopped working, I’m getting the same error message again.

    Hey @exxis

    ​Sorry to hear about that!

    I hope you checked with your host if anything changed on their end regarding permissions?

    Also, did you do any changes in terms of WP installation, moved it to another folder, or did anything that could be suspicious?

    What you can do is to activate this helper plugin and check its Info page. Can you tell me if there is any field with red background, especially in the first sections of the page where is the info about location and paths?

    Thanks!
    Marko

    Hi,
    I too have the same problem. Why don’t you integrate it in the Plugin core?
    I installed the “Imagify Custom Site Root” plugin and solved it but disabling it the problem comes back.
    Thanks

    Hello @sermatica,

    Thank you for your feedback on this!

    I can’t know for sure what decisions will be made in the future, but our team will certainly consider it as we move forward and try to improve Imagify!

    Hope you have a very nice rest of your day!

    Best regards,

    Hi,
    Yes, I’m getting the same error and after installing Imagify tool helper function able to see errors in RED which are below

    1) $_POST requests to https://stage.bradleysfish.com/wp-admin/admin-ajax.php blocked

    Request returned an error:

    cURL error 28: Operation timed out after 10000 milliseconds with 0 bytes

    2) $_POST requests to http://stage.bradleysfish.com/wp-cron.php blocked Request returned an error:

    cURL error 28: Operation timed out after 10001 milliseconds with 0 bytes

    Hi @snehaladdweb

    I am sorry to hear that.

    Those blocked requests may happen when there is a large request for optimization and lead your server to timeout. You will have to contact your host provider in order to unblock the requests and check if there is a firewall or security module that could block wp-cron.php self-request or if there is some limitation with wp-cron.

    Please let me know how it goes.

    Best regards,
    Ioanna

    Hi,

    Just came across this thread with a similar problem. This has occurred since my site was migrated to a new server. I then removed and reinstalled the backup plugin BackWPup but the same problem still persists. However, my new back up to drop box appears to be functioning OK, but I’m still getting the following error message on my wordpress dash:

    Your backup folder is NOT writable
    
    To correct this issue, make the folder writable.
    
    Your backup folder MIGHT be visible to the public
    
    To correct this issue, move the file from /home/dlila77qekrk/public_html/wp-content/plugins/wp-dbmanager/htaccess.txt to /.htaccess
    
    To correct this issue, move the file from /home/dlila77qekrk/public_html/wp-content/plugins/wp-dbmanager/index.php to /index.php
    
    Click here to let WP-DBManager try to fix it

    Hey @seabass888

    Thanks for your feedback!

    Just to be sure, you have a same problem with Imagify?

    As this is definitely related to the communication with server and it could happen with any plugin that has to make changes in uploads (or other) folder.

    Best Regards

    Thanks for the reply.

    No I don’t have the plugin Imagify. I was assuming my problem was specific to the plugin BackWPup. I’ve removed and then re-installed this plugin and have successfully created a new back up to Dropbox, however I still get this error message on my WP dashboard, and cannot remove. I’m a beginner wordpress developer, so no experience/knowledge. If I “Click here to let WP-DBManager try to fix it”. I get the following specific error text:
    “`Checking Security Status
    .htaccess is missing from

    index.php is missing from

    Checking Backup Status
    Checking Backup Folder () …
    Backup folder does NOT exist. Please create ‘backup-db’ folder in ‘/home/dlila77qekrk/public_html/wp-content’ folder and CHMOD it to ‘777’ or change the location of the backup folder under DB Option.

    Backup folder is NOT writable. Please CHMOD it to ‘777’.

    Checking MYSQL Dump Path (/usr/bin/mysqldump) …

    MYSQL dump path exists.

    Checking MYSQL Path (/usr/bin/mysql) …

    MYSQL path exists.

    Checking PHP Functions (passthru(), system() and exec()) …
    passthru() enabled.

    system() enabled.

    exec() enabled.

    Please Rectify The Error Highlighted In Red Before Proceeding On.

    Note: The checking of backup status is still undergoing testing, it may not be accurate.`

    I added the MYSQL Dump Path and the MYSQL Path – they had automated options to add. However the main error remains. Do i understand where I can add my new DB back up folder, and would have thought if i was backing up to Dropbox, why this is occurring? Please note this has problem has occured since my site was moved to a new server. I also fear I may have deleted a previous folder on my server when trying to remove the last back up and create a new one, but to be honest, I can’t specifically remember. Anyway, you can see the error message above. Please assist if possible. I guess the solution appears to be creating a new back up db folder in /home/dilila……etc.
    However, where do I create this? If this is the problem/solution? Thanks

  • Viewing 15 replies — 1 through 15 (of 16 total)

    Исправить Невозможно создать каталог wp-content / uploads Ошибка WordPress

    Я только что перенес свои данные WordPress на новый сервер. После этого я не могу загрузить ни один медиафайл.

    На панели управления отображается сообщение об ошибке «Папка загрузки недоступна для записи. Функции экспорта и загрузки файлов не будут работать».

    • Готов поспорить, что безопасный режим включен на сервере, на который вы только что перешли.

    Вам необходимо обновить разрешения для каталога загрузки.

    если у вас есть доступ по ssh, что-то вроде chmod a+w wp-content/uploads или если вы используете какой-либо FTP-клиент, попробуйте щелкнуть правой кнопкой мыши по папке и установить group или all разрешение на запись.

    Если вы не знаете, где находится ваша папка с загрузками, вы можете проверить wp-config.php для этой линии define( 'UPLOADS', YOUR UPLOAD FOLDER HERE);

    • Я столько раз обновлял разное количество. Подскажите точное количество и папку. Я попытался внести изменения в папку ЗАГРУЗКИ, 2014/09 и index.php
    • Вероятно, у вас по умолчанию wp-content/uploads/, но вы можете проверить, отметившись wp-config.php для чего-то вроде define( 'UPLOADS', YOUR UPLOAD FOLDER HERE);.

    Зависит от вашего окружения. Узнайте, какой пользователь использует wordpress, и запустите следующее:

    chown -R user:group /root/of/install/wp-content/uploads chmod -R 755 /root/of/install/wp-content/uploads 

    замените ‘user’ на пользователя, от имени которого запускается wp, и сделайте то же самое для ‘group’, убедитесь, что приложение ftp, которое вы используете, запускается от имени того же пользователя, что и ‘user’ выше

    если вы не заботитесь о безопасности, вы можете просто запустить

    chmod -R 777 /root/of/install/wp-content/uploads 

    HTH

    У меня возникла эта проблема после переноса сайта на новый сервер.

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

    Проблема в том, что иногда WordPress заполнит опцию под названием upload_path в wp_options Таблица. Очень похоже на комментарий выше с PHP Define: 'UPLOADS' это может быть установлено в вашем wp-config.php это не идеально, так как жестко кодирует ваши пути.

    Так что исправить довольно просто, вам нужно Чисто (как в случае удаления) либо ключ из wp_options table или просто значение этого ключа.

    Как это сделать? Внутри WordPress есть удобный способ сделать это: (осторожно: будьте осторожны, чтобы не изменять никакие другие поля на следующих шагах, кроме того, которое вы ищете).

    1. Войдите в свой WP Admin
    2. Перейдите по этому URL-адресу на своем сайте: /wp-admin/options.php. Это предоставит вам полный список параметров WP в вашем wp_options таблица базы данных.
    3. Найдите (Ctrl + F) следующее название опции: upload_path
    4. Если у него есть значение, просто удалите то, что находится в этом поле.
    5. Больше ничего не меняйте и нажмите Save Changes внизу

    Затем WordPress начнет использовать путь по умолчанию (/wp-content/uploads/) в папку загрузок

    Папка загрузки была недоступна для записи. Путь загрузки нужно было удалить в базе данных> таблица wp_options.

    • 1, возможно, вы захотите сделать этот ответ более подробным, чтобы прояснить, как, по вашему мнению, параграфы должны решить проблему.

    Я решил эту проблему, выполнив следующие действия:

    1. Откройте myphpadmin через cpanel и откройте свою базу данных.

    2. Выбрать таблицу опций

    3. Найдите строку с именем upload_url и нажмите изменить.

    4. Удалите значение и нажмите «Сохранить».

    Tweet

    Share

    Link

    Plus

    Send

    Send

    Pin

  • Ошибка панорама дота 2
  • Ошибка панель управления nvidia доступ запрещен не удалось применить выбранные настройки к системе
  • Ошибка панель приборов газель ebd
  • Ошибка память не может быть ред
  • Ошибка память не может быть реад