file_put_contents (मेटा / services.json): स्ट्रीम खोलने में विफल: अनुमति से इनकार किया


168

मैं लारावेल के लिए नया हूं। मैं खोलने की कोशिश कर रहा थाhttp://localhost/test/public/ और मुझे मिल गया

अपवाद हैंडलर में त्रुटि।

मैंने चारों ओर गुगली की और भंडारण निर्देशिका का उपयोग करके अनुमति बदल दी chmod -R 777 app/storage लेकिन कोई फायदा नहीं हुआ।

में बदल debug=>trueगयाapp.php और पेज का दौरा किया और अपवाद संचालक करने में त्रुटि है:

स्ट्रीम या फ़ाइल "/var/www/html/test/app/storage/logara/laravel.log" को खोला नहीं जा सका: स्ट्रीम को खोलने में विफल: अनुमति / var / www / html / परीक्षण / बूटस्ट्रैप / संकलित में अस्वीकृत। php: 8423

फिर मैंने कमांड का उपयोग करके भंडारण निर्देशिका की अनुमतियों को बदल दिया chmod -R 644 app/storage और 'अपवाद हैंडलर में त्रुटि' त्रुटि चली गई और एक पेज लोड हो गया। लेकिन वहां मुझे यह मिल रहा है:

file_put_contents (/var/www/html/laravel/app/storage/meta/services.json): स्ट्रीम खोलने में विफल: अनुमति अस्वीकृत


2
फिर से परमिट जारी करने जैसा लगता है, सभी आवेदन निर्देशिकाओं को फिर से chmod करें
alou

@alou मुझे लगता है कि मैंने पहले ही chmod -R 777 ऐप / स्टोरेज के साथ किया है। मैं नहीं था? और एप्लिकेशन के अंदर सभी निर्देशिकाओं में drwxrwxrwx अनुमति है।
vishnub1626

33
कोशिश करें: php artisan cache:clearफिर chmod -R 777 app/storageअंत मेंphp artisan dump-autoload
vsmoraes

@vsmoraes यह काम किया। यह वास्तव में उपयोगी होगा यदि आप बता सकते हैं कि समस्या क्या थी।
vnnub1626

7
हालांकि, बनाम 'कारीगर डंप-ऑटोलॉड' के बजाय 'संगीतकार डंप-ऑटोलॉड' होना चाहिए - vsmoraes की टिप्पणी सही थी
इलियट रॉबर्ट

जवाबों:


320

Vsmoraes से सुझाव मेरे लिए काम किया:

लारवेल> = 5.4

php artisan cache:clear 
chmod -R 777 storage/
composer dump-autoload

लारवेल <5.4

php artisan cache:clear 
chmod -R 777 app/storage 
composer dump-autoload

नोट: किसी भी रिमोट सर्वर (उत्पादन या उत्पादन) पर इस मत करो

जब मैंने यह सवाल पूछा, तो यह एक वर्चुअल मशीन में चलने वाली मेरी लोकलहोस्ट पर एक समस्या थी। इसलिए मैंने सोचा कि 777 की स्थापना काफी सुरक्षित थी, हालांकि, लोग सही हैं जब वे कहते हैं कि आपको एक अलग समाधान की तलाश करनी चाहिए। पहले 775 का प्रयास करें


8
यह sudo chmod -R 777 ऐप / स्टोरेज होना चाहिए। अनुमति त्रुटि से बचने के लिए।
Olaitan Mayowa

5
# Laravel5 के लिए निर्देश लगभग समान हैं:, php artisan cache:clearतब chmod -R 777 storage, और फिर composer dump-autoload
WNRosenberg

6
यदि आप लारवेल 5.1+ का उपयोग कर रहे हैं तो आपको chmod -R 777 storageइसके बजाय
जेम्स

10
php artisan cache:clearसही उत्तर है। फिर sudo chmod -R ug+rw storageमेरे लिए सही अनुमति देता है, बिना othersपढ़े / लिखे या विशेष रूप से विशेषाधिकार निष्पादित किए बिना ।
ज़ैक मॉरिस

43
यह उत्तर और धागा वह है जो हाइलाइट करता है कि मैं लारवेल को क्यों नापसंद करता हूं: यह डेवलपर्स को सिखाता है कि आप जब चाहें, तब तक कुछ भी कर सकते हैं, जब तक आप चाहते हैं, परिणामों के बारे में सोचे बिना (मैं समझता हूं कि 777लारवेल विशिष्ट नहीं है, लेकिन लारवेल डेवलपर्स के लिए विचार प्रक्रिया है: "इसे अभी काम करो, मुझे परवाह नहीं है", बस की तरह 777)। एक सामान्य नियम के रूप में, कभी भी, कभी भी, कुछ भी 777काम करने के लिए निर्धारित करें । अपने सर्वर और उपयोगकर्ताओं / भूमिकाओं को पूरा करें और तदनुसार उन्हें सेट करें; उस पर हैक मत करो। आपके ग्राहकों को यह अधिकार करने के लिए आप पर भरोसा है।
dKen

70

लारावेल 5 के साथ इस समस्या का सामना करने वाले गोगलर्स के लिए।

यह विभिन्न उपयोगकर्ताओं द्वारा अलग- storage/logsअलग अनुमतियों के साथ फ़ोल्डर में एक ही लॉग फ़ाइल पर लिखने की कोशिश करने के कारण होता है ।

क्या होता है आपका लार्वा कॉन्फिगर शायद लॉग इन त्रुटियों के लिए प्रतिदिन सेटअप होता है और इसलिए आपका वेबसर्वर (Apache / nginx) इस फाइल को एक डिफ़ॉल्ट उपयोगकर्ता के तहत बना सकता है जो आपके वातावरण के आधार पर हो सकता है कि यह _wwwOSX या www-data* NIX सिस्टम पर कुछ हो , फिर मुद्दा तब आता है जब आपने कुछ कारीगर कमांड चलाए होंगे और कुछ त्रुटियां हुई होंगी, इसलिए कारीगर इस फाइल को लिखेंगे लेकिन एक अलग उपयोगकर्ता के साथ क्योंकि टर्मिनल पर PHP को एक अलग उपयोगकर्ता द्वारा वास्तव में आपके लॉगिन उपयोगकर्ता द्वारा निष्पादित किया जाता है, आप इस कमांड को चलाकर इसे देख सकते हैं। :

php -i | grep USER

यदि आपका लॉगिन उपयोगकर्ता आपके वेबसर्वर को लॉग इन करता है, तो आप उसमें त्रुटियां नहीं लिख पाएंगे और इसके विपरीत, क्योंकि लार्वा लॉग फाइल के साथ लिखते हैं 655 डिफ़ॉल्ट रूप से अनुमतियों के जो केवल मालिक को उसमें लिखने की अनुमति देता है।

इस अस्थायी को ठीक करने के लिए आपको समूह को मैन्युअल रूप 664से इस फ़ाइल की अनुमति देनी होगी ताकि आपका लॉगिन उपयोगकर्ता और वेबसर्वर उपयोगकर्ता दोनों उस लॉग फ़ाइल में लिख सकें।

इस समस्या से स्थायी रूप से बचने के लिए आप एक नई फ़ाइल बनाते समय एक उचित अनुमतियाँ सेटअप करना चाहते हैं storage/logs निर्देशिका से अनुमतियाँ प्राप्त करके dir के तो यह उत्तर https://unix.stackexchange.com/a/115632 से निपटने में आपकी सहायता कर सकता है। उस।


प्रशंसक- friggen-tastic जवाब यहाँ! मैं इलास्टिक बीनस्टॉक पर चल रहा हूं और मेरी कमांड-लाइन PHP उपयोगकर्ता "ec2-user" है, लेकिन मेरा आवेदन "webb" के रूप में चलता है।
रैंडी एल

1
एक जवाब जो समस्या की व्याख्या करता है। यानी एक उचित जवाब।
१०:१३ पर क्रेसीरजैक

इससे मुझे एहसास हुआ कि मुझे क्लाउडवे पर लारवेल में एक फ़ाइल कैश त्रुटि क्यों मिल रही थी। फ़ाइल अनुमतियाँ रीसेट करने के लिए मुझे क्लाउडवे पैनल में बटन दबाना होगा। धन्यवाद।
रयान

44

आपको 777 अनुमतियां नहीं देनी चाहिए। यह एक सुरक्षा जोखिम है। उबंटू उपयोगकर्ताओं के लिए, लारावेल 5 में, मैं निर्देशिका भंडारण के लिए मालिक को पुनरावर्ती रूप से बदलने के लिए सबसे आगे हूं:

निम्नलिखित का प्रयास करें:

sudo chown -R www-data:www-data storage

उबंटू आधारित प्रणालियों में, www-data एपाचे उपयोगकर्ता है।


2
यह मेरे लिए तय है, और chmod 777उत्तरों की तुलना में अधिक सही है (मुझे लगता है) । धन्यवाद ~
गेविनर २ '

मुझे लगता है कि यह लिनक्स उपयोगकर्ताओं के लिए सबसे सुविधाजनक उत्तर है। धन्यवाद @GavinR chmod 777एक बुरा सपना है।
अब्दुल्ला अरबब

यह मेरे लिए काम किया और निश्चित रूप से chmod -777 से बेहतर विकल्प है
Egnaro

समस्या को हल करने के नए तरीके के लिए धन्यवाद! क्या chmod 777परिणाम को उलटने के लिए हमें आपकी आज्ञा से पहले / बाद में कुछ करने की आवश्यकता है ?
अलेक्जेंडर

41

Laravel 5, Homestead और Mac का उपयोग करने वाले सभी के लिए यह प्रयास करें:

mkdir storage/framework/views

यह भी Laravel
5.2.7 के

2
इसने मेरे लिए यह किया। ऐसा लगता है जैसे bootstrap/cache/compiled.phpइस निर्देशिका को लिखने की कोशिश कर रहा था, लेकिन यह मौजूद नहीं था और अनुमतियाँ त्रुटि को समाप्त कर दिया। धन्यवाद।
मैट के

1
किसी तरह यह मेरे लिए काम किया। मैं
लार्वा

यह मेरे लिए किया, धन्यवाद। मैंने अपनी पूरी स्टोरेज डायरेक्टरी को यह सोचकर हटा दिया था कि यह लार्वा द्वारा फिर से उत्पन्न होगा, अनुमान नहीं।
१०:१६ पर ग्रिमडूड

33

कुछ बार SELINUX ने इस समस्या का कारण बना; आप इस आदेश के साथ सेलिनक्स को अक्षम कर सकते हैं।

sudo setenforce 0

वाह, मैं वास्तव में चाल और काम करता था, क्या कोई मुझे समझा सकता है कि यह क्यों काम किया? सेलिनक्स क्या है?
अपरिभाषित

हाँ, यह वास्तव में काम किया! कृपया हमें SELINUX पर इसे समझने में गुरु की मदद करें? im फेडोरा 24 btw का उपयोग कर
loki9

1
थैंक यू, थैंक यू सो मच। मैं नेट
खोजता

3
यह मूल रूप से पूरे फ़ायरवॉल को बंद करने जैसा है क्योंकि यह आपके द्वारा खुले एक पोर्ट को अवरुद्ध कर रहा था।
तेह जोई

मैंने यह कभी नहीं सुना था। "सुरक्षा-संवर्धित लिनक्स (SELinux) एक लिनक्स कर्नेल सुरक्षा मॉड्यूल है जो एक्सेस कंट्रोल सुरक्षा नीतियों का समर्थन करने के लिए एक तंत्र प्रदान करता है।" मुझे संदेह है कि इसे बंद करना एक अच्छा विचार है। और मैं शर्त लगाता हूं कि upvoters नेत्रहीन रूप से इस आदेश का उपयोग पूर्ण परिणामों को समझने के बिना कर रहे हैं।
रियान

18

समस्या सुलझ गयी

php artisan cache:clear
sudo chmod -R 777 vendor storage

यह एप्लिकेशन, रूपरेखा, लॉग्स के लिए लेखन अनुमति को सक्षम करता है। आशा है कि यह मदद करेगा


12
777 में कभी नहीं ... देव या ठेस के रूप में यह देव में काम कर रहे चीजों का भ्रम देगा, लेकिन वे ठेस में तब तक टूटेंगे जब तक कि 777 के रूप में अच्छी तरह से एक अच्छा विचार नहीं है
काइल बर्कट

wooha you rock ... वेंडर वह था जिसे मैं याद कर रहा था
lu1s

हाँ, 777 पर एक सार्वजनिक सामना कर रहे वेब पर कुछ भी देना एक बुरा विचार है
imabug

17

कभी भी यह 777 नहीं दें!

अपने टर्मिनल पर लार्वा परियोजना की निर्देशिका में जाएं और लिखें:

sudo chown -R your-user:www-data /path/to/your/laravel/project/
sudo find /same/path/ -type f -exec chmod 664 {} \;
sudo find /same/path/ -type d -exec chmod 775 {} \;
sudo chgrp -R www-data storage bootstrap/cache
sudo chmod -R ug+rwx storage bootstrap/cache

इस तरह से आप अपने उपयोगकर्ता को स्वामी बना रहे हैं और विशेषाधिकार दे रहे हैं:
1 निष्पादित करें, 2 लिखें, 4 पढ़ें
1 + 2 + 4 = 7 का अर्थ है (rwx)
2 + 4 = 6 का अर्थ है (rw)
अंत में, स्टोरेज एक्सेस के लिए, ug + rwx का अर्थ है कि आप उपयोगकर्ता और समूह को 7 दे रहे हैं


1
मुझे नहीं पता कि 777 का उपयोग करना क्यों पसंद है ... किसी तरह वे अपनी प्रणाली के बारे में परवाह नहीं करते थे ...
ज़ीरोएन

15

योनि उपयोगकर्ताओं के लिए, समाधान है:

(आवारा में) php कारीगर कैश: स्पष्ट

(आवारा के बाहर) chmod -R 777 ऐप / स्टोरेज

(आवारा में) संगीतकार डंप-ऑटोलॉड

सुनिश्चित करें कि आप अपने स्थानीय वातावरण में चामोद करते हैं और योनि के अंदर नहीं, यहाँ महत्वपूर्ण है!


6
777 भी खुला नहीं है?
simo

3
मेरा मतलब है, उत्पादन के लिए, निश्चित। लेकिन यह स्थानीय देव वातावरण है। 777 मूल पोस्टर का उपयोग कर रहा था, और अन्य उत्तर। 775 या 755 के आधार पर काम कर सकते हैं।
ब्रेंडन

12

फिर से प्रयास करें chmod -R 755 /var/www/html/test/app/storageOperation not permittedचामोद में सूडो के साथ प्रयोग करें । यदि अभी भी त्रुटि हो रही है, तो स्वामी की अनुमति का उपयोग करें।


काम नहीं कर रहा। एप्लिकेशन के अंदर सभी निर्देशिकाओं की अनुमति है drwxrwxrwx
vishnub1626

@ क्या आप अपने परीक्षण फ़ोल्डर के लिए अपने स्वामी की अनुमति की जांच कर सकते हैं?
खाय

एक ही drwxrwxrwx। @ Vsmoraes के सुझावों (टिप्पणियों को देखें) का उपयोग करके समस्या का हल किया
vishnub1626

4
chmod 777 एक सुरक्षा जोखिम है
योगेश कामत

9

Laravel 5.4 के अनुसार, जो नवीनतम है जैसा कि मैं यह लिख रहा हूं, यदि आपको इस तरह की कोई समस्या है, तो आपने अनुमति बदलने के लिए ned किया है। किसी भी व्यक्ति के लिए 777 सेट करने के लिए आपको सूचित नहीं करता है। इसका सुरक्षा मुद्दा है। इस तरह स्टोरेज फोल्डर की अनुमति बदलें

sudo chmod -R 775 storage

बूटस्ट्रैप फ़ोल्डर की अनुमति को इस तरह बदलें

sudo chmod -R 775 bootstrap/cache

अब कृपया सुनिश्चित करें कि आप अपने एप्लिकेशन डायरेक्टरी से दोनों कमांड निष्पादित कर रहे हैं। अनुमति के संबंध में आपको भविष्य में समस्याओं का सामना नहीं करना पड़ेगा। 775 आपकी मशीन की किसी भी सुरक्षा से समझौता नहीं करता है।


7

सही अनुमति का सुझाव दें, यदि Apache के लिए,

sudo chown -R apache:apache apppath/app/storage

लारवेल फोर्ज का उपयोग: सूडो चाउन-आर फोर्ज: फोर्ज ~ / प्रोजेक्ट / स्टोरेज / सुडो चाउन-आर फोर्ज: फोर्ज ~ / प्रोजेक्ट / बूटस्ट्रैप / कैश /
Flappy

6

यदि आपके पास Laravel 5 है और स्थायी समाधान खोज रहे हैं, तो php artisanकमांड लाइन उपयोग और अपाचे सर्वर दोनों का उपयोग करें:

sudo chmod -R 777 vendor storage
echo "umask 000" | sudo tee -a /etc/resolv.conf
sudo service apache2 restart

विस्तृत विवरण यहाँ देखें ।


8
यह 777
रैंडी एल

umask 000 को resolv.conf में! यह जानकारी लोगों को कहां मिल रही है? यह resolv.conf में एक अमान्य रेखा है। कृपया इसे नजरअंदाज करें और सभी 777 "समाधान" वहाँ से बाहर करें
higuita

url की जाँच करें और resolv.conf linux.die.net/man/5/resolv.conf
higuita

6

SELINUX के साथ किसी OS को रनिंग के लिए: httpd को लार्वा स्टोरेज फ़ोल्डर में लिखने की अनुमति देने का सही तरीका है:

sudo semanage fcontext -a -t httpd_sys_rw_content_t '/path/to/www/storage(/.*)?'

फिर तुरंत परिवर्तन लागू करने के लिए:

sudo restorecon -F -r '/path/to/www/storage'

SELinux से निपटने के लिए एक दर्द हो सकता है, लेकिन अगर यह मौजूद है तो मैं पूरी तरह से आपको इसके बजाय इसे पूरी तरह से दरकिनार करने के बजाय सीखूंगा।


ताजा सेंटो 7 में मेरी सटीक समस्या समान थी। यह लिखने के लिए कोई अनुमति नहीं कह रहा था, लेकिन सभी परीक्षण के लिए 777 थे। इसलिए इस पोस्ट ने वास्तव में सभी सामान्य जांच के बाद मेरा समय बचाया।
HumaN

1
यह सही समाधान है, हालांकि मुझे लगता है कि सही SELinux टाइप sudo semanage fcontext -a -t httpd_sys_rw_content_t '/path/to/www/storage(/.*)?'
httpd_sys_rw_content_t

4

मेरे पास एक ही मुद्दा था और नीचे दिए गए कदमों ने मुझे समस्या को ठीक करने में मदद की।

  1. अपाचे उपयोगकर्ता का पता लगाएं - कोड के साथ सार्वजनिक फ़ोल्डर में एक test.php फ़ाइल बनाई

<?php echo exec('whoami'); ?>

और वेब ब्राउजर से फाइल को रन करें। यह अपाचे उपयोगकर्ता देगा। मेरे मामले में, यह ec2-user है क्योंकि मैं /etc/cron.d/ में cronjob के साथ aws का उपयोग कर रहा था। यह दूसरों के लिए अलग उपयोगकर्ता हो सकता है।

  1. कमांड लाइन पर नीचे कमांड चलाएं।

sudo chown -R ec2-user:<usergroup> /app-path/public

आपको यहां सही "उपयोगकर्ता" और "उपयोगकर्ता समूह" को पहचानने और उपयोग करने की आवश्यकता है।


4

यदि आप लिनक्स या मैक का उपयोग करते हैं, तो भी आप में भी चल सकते हैं ssh terminal। आप इस कमांड को चलाने के लिए टर्मिनल का उपयोग कर सकते हैं,

 php artisan cache:clear 
 sudo chmod -R 777 storage
 composer dump-autoload

यदि आप विंडोज़ का उपयोग कर रहे हैं, तो आप उपयोग कर सकते हैं git bash

 php artisan cache:clear 
 chmod -R 777 storage
 composer dump-autoload

आप git form https://git-scm.com/downloads डाउनलोड कर सकते हैं ।


3

उपयोग के लिए Xampp:

cd /Applications/XAMPP/htdocs  
chmod -R 775 test/app/storage

1
क्या आप इसे थोड़ा और अलग कर सकते हैं?
आरोन हॉल

मैं इस लेख का उपयोग करता हूं, और मैं था: मैक ओएसएक्स पर लारवेल 4.x की स्थापना। XAMPP के साथ 10.8+
cristianojeda

3
chmod 777 एक सुरक्षा जोखिम है
योगेश कामत

1
तुम भी इस chmod 775
cristianojeda

2

किसी भी समय मैं app.php को बदल देता हूं, मुझे बूटस्ट्रैप / कैश / सेवाओं को लिखने से इनकार करने की अनुमति मिलती है। इसलिए मैंने इसे ठीक करने के लिए ऐसा किया है:

chmod -R 777 bootstrap/cache/

8
chmod 777 एक सुरक्षा जोखिम है
योगेश कामत


2

777 की अनुमति देना निश्चित रूप से भयानक विचार है!

... परंतु

यदि आपको "स्टोरेज" फ़ोल्डर से जुड़ी अनुमति त्रुटि मिल रही है तो मेरे लिए क्या काम किया है:

1) 777 के साथ "भंडारण" और उसके सबफ़ोल्डर्स की अनुमति सेट करें

sudo chmod -R 777 storage/

2) ब्राउज़र में लार्वेल होम पेज लार्वेल / पब्लिक / पर जाएं (लार्वा आवश्यक प्रारंभिक भंडारण फाइलें बनाएगा)

3) भंडारण और उसके सबफ़ोल्डरों के लिए सुरक्षित 775 अनुमति लौटाएं

sudo chmod -R 775 storage/

2

यदि लैराडॉक का उपयोग कर रहे हैं, तो chown -R laradock:www-data ./storageअपने कार्यक्षेत्र कंटेनर में प्रयास करें


1

मेरे मामले में समाधान के लिए अनुमति app/storage/framework/viewsऔर app/storage/logsनिर्देशिकाओं को बदलना था ।


0

अगर किसी और को fopen फ़ाइल अनुमतियों की त्रुटि के साथ इसी तरह के मुद्दे में चलता है, लेकिन बुद्धिमानी से 777 आँख बंद करके नहीं है यहाँ मेरा सुझाव है।

आप जिन अनुमतियों के लिए अपाचे की जरूरत है, उनके लिए कमांड का उपयोग करें:

fopen('filepath/filename.pdf', 'r');

'आर' का मतलब केवल पढ़ने के लिए खुला है, और यदि आप फ़ाइल को संपादित नहीं कर रहे हैं, तो यह वही है जो आपको इसे सेट करना चाहिए। इसका मतलब है कि अपाचे / www-डेटा को उस फ़ाइल पर कम से कम पढ़ने की अनुमति की आवश्यकता है, जो यदि फ़ाइल लार्वा के माध्यम से बनाई गई है, तो इसकी अनुमति पहले से ही होगी।

यदि किसी भी कारण से आपको फाइल पर लिखना है:

fopen('filepath/filename.pdf', 'r+');

फिर सुनिश्चित करें कि अपाचे के पास फ़ाइल को लिखने की अनुमति भी है।

http://php.net/manual/en/function.fopen.php


0

बस अपने सर्वर का उपयोग शुरू करें artisian

php artisian serve

फिर अपने प्रोजेक्ट को निर्दिष्ट URL से एक्सेस करें:

यहां छवि विवरण दर्ज करें


0

मैं एक ही मुद्दा है जब मैक पर आवारा चल रहा है। Apache सर्वर के उपयोगकर्ता को https.conf फ़ाइल में बदलकर समस्या हल की:

# check user for php
[vagrant] ubuntu ~ $ php -i | grep USER
USER => ubuntu
$_SERVER['USER'] => ubuntu
[vagrant] ubuntu ~ $ 

Php के साथ फ़ाइल पहुँच समस्या को हल करने के लिए उपयोगकर्ता डेमॉन के बजाय php उपयोगकर्ता के अंतर्गत अपाचे चलाएँ

# change default apache user from daemon to php user
sudo sed -i 's/User daemon/User ubuntu/g' /opt/lampp/etc/httpd.conf
sudo sed -i 's/Group daemon/Group ubuntu/g' /opt/lampp/etc/httpd.conf

अब, php निर्मित कैश फ़ाइल को बिना किसी एक्सेस अनुमति त्रुटि के अपाचे द्वारा पढ़ा और संपादित किया जा सकता है।


0

निर्देशिका अनुमतियों के साथ बहुत सारे परीक्षण और त्रुटि के बाद मैं एक एपिफनी के साथ समाप्त हो गया ... डिस्क के विभाजन पर कोई जगह नहीं बची थी। बस यह सुनिश्चित करने के लिए साझा करना चाहता था कि गलत दिशा में समाधान खोजने के लिए कोई और मूर्ख नहीं है।

लिनक्स में आप df -hअपने डिस्क के आकार और खाली जगह की जांच कर सकते हैं ।


0

यह समस्या वास्तव में विभिन्न उपयोगकर्ताओं के कारण है जो चाहते हैं write/read फाइल हैं लेकिन अलग-अलग स्वामित्व का कारण बनते हैं। हो सकता है कि पहले आप 'रूट' के रूप में स्थापित किए गए लार्वा से पहले आप अपनी साइट में 'लार्वेल' उपयोगकर्ता के रूप में लॉग इन करें, जहां 'लार्वेल' डिफ़ॉल्ट स्वामित्व है, इसलिए यह वास्तव में यहां वास्तविक मुद्दा है। इसलिए जब उपयोगकर्ता 'लार्वेल' डिस्क में सभी फ़ाइल को डिफ़ॉल्ट रूप में पढ़ना / लिखना चाहता है, तो इनकार किया जाना चाहिए, क्योंकि उस फ़ाइल का मूल 'रूट' है।

इस समस्या को हल करने के लिए आप इस तरह का अनुसरण कर सकते हैं:

sudo chown -hR your-user-name /root /nameforlder

या मेरे मामले में

sudo chown -hR igmcoid /root /sublaravel

पाद लेख:

  1. root पहले स्वामित्व के नाम के रूप में जो पहले स्थापित है
  2. your-user-name डिफ़ॉल्ट स्वामित्व के रूप में जो वास्तव में साइट में लिखते / पढ़ते हैं।
  3. namefolder नाम फ़ोल्डर के रूप में जो आप स्वामित्व बदलना चाहते हैं।

0

मुझे अपने प्रोजेक्ट में समान त्रुटियां
मिलीं ... लेकिन पता चला कि मैं enctypeअपने फॉर्म में डालना भूल गया हूं।

<form method="#" action="#" enctype="multipart/form-data">

आशा है कि यह किसी तरह कहीं मदद करता है ...


0

लैरैगन और लारवेल 4 के साथ विंडोज 10 पर काम करते समय, मुझे ऐसा लगा कि मैन्युअल रूप से अनुमतियों को बदलने का कोई तरीका नहीं है, क्योंकि chmodलारगन-इन-बिल्ट-टर्मिनल में -commands का कोई प्रभाव नहीं था।

हालाँकि, इस टर्मिनल में स्टोरेज फोल्डर में जाना और मैन्युअल रूप से इस तरह वांछित फ़ोल्डर जोड़ना संभव था:

cd app/storage
mkdir cache
mkdir meta
mkdir views
mkdir sessions

cdटर्मिनल में -command (यदि आप अपने फ़ाइल संरचना के अनुरूप करने के इस पथ समायोजित करने के लिए आवश्यकता हो सकती है) फ़ोल्डर में ले आता है। mkdir-Command दिए गए नाम के साथ निर्देशिका का निर्माण करेगा।

मेरे पास लारवेल 5 में इस दृष्टिकोण का परीक्षण करने का अवसर नहीं था, लेकिन मुझे उम्मीद है कि एक समान दृष्टिकोण काम करना चाहिए।

बेशक एक बेहतर तरीका हो सकता है, लेकिन कम से कम यह मेरी स्थिति के लिए एक उचित समाधान था (त्रुटि को ठीक करना:) file_put_contents(/var/www/html/laravel/app/storage/meta/services.json): failed to open stream


-1
  1. सबसे पहले स्टोरेज फोल्डर को डिलीट करें फिर स्टोरेज फोल्डर बनाएं।
  2. अंदर भंडारण फ़ोल्डर एक नया फ़ोल्डर नाम फ्रेमवर्क के रूप में बनाते हैं।
  3. अंदर की रूपरेखा फ़ोल्डर कैश, सत्र और विचारों के रूप में तीन फ़ोल्डर नाम बनाते हैं।

मैंने ऐसा करके अपनी समस्या हल कर ली है।


-4

मैंने 777भंडारण फ़ोल्डर तक पहुंच देने की कोशिश की है और यह मेरे लिए काम करता है

1) अपने लार्वा रूट डायरेक्टरी (( /var/www/htmlमेरे लिए) पर जाएं और निम्न कमांड चलाएँ

chmod 777 -R storage

2
777 के लिए अनुमतियाँ सेट न करें क्योंकि यह डीआईआर को सभी के लिए दृश्यमान और संपादन योग्य बनाता है जो डायर को देख सकते हैं। यह अनुशंसित नहीं है!
कोडनिजा
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.