Reading Dette
WordPress Fejlfinding: Tilladelser, CHMOD og stier, Oh My!
Med spørgsmål i forbindelse med varierende Shared hosting pakker, osv. versioner af PHP, Apache, fil tilladelse spørgsmål undertiden opfostre deres grimme hoved. Jeg håber følgende reference kan give nogle hjælp eller retning til de mindre erfarne:
En "file not found" "404", "Kan ikke oprette mappe", "Kan ikke åbne" eller "eksisterer ikke" fejl stopper ting døde i deres spor. Dette er normalt på grund af et program / script ikke finde et script eller en fil, hvor man forventer at kunne, eller det ikke er 'tilladt' for at se det på grund af tilladelses indstillingerne på den fil eller det bibliotek.
Lad os begynde med stien. Check din fejl omhyggeligt, vil det normalt liste stien til filen i spørgsmålet. Jeg anbefaler at bruge FileZilla FTP-program. 
Åben FileZilla og oprette forbindelse til dit websted. Navigere gennem den sti, der er anført i fejlen og forsøge at finde filen. Hvis det mangler, så prøv at lægge den op igen og prøve ... Hvis stien er forskellige, verificere, hvis du har installeret wordpress i 'top' eller rodmappen, eller hvis det er i en sub-bibliotek.
Hvis du har fundet den, og stien er korrekt, tjekke tilladelserne.
I dette eksempel, vil jeg nummer tilladelserne flag:
drwxrwxrwx 1234567890
1 mappe flag, 'd', hvis et bibliotek, '-', hvis en normal fil, lejlighedsvis 'l' for et link.
2,3,4 læse, skrive, køretilladelse for User (Ejer) af fil
5,6,7 læse, skrive, køretilladelse for koncernen
8,9,0 læse, skrive, køretilladelse til andre (også kaldet 'alle').
- I enhver situation betyder, at flaget er ikke indstillet
r fil kan læses af ejer, gruppe eller andre
w fil er skrivbar. På et bibliotek, adgang skrive betyder, at du kan tilføje eller slette filer
x-filen er eksekverbar fil (kun til programmer og shell-scripts - ikke er nyttige for data-filer). Køretilladelse på et bibliotek betyder, kan du sortere filerne i denne mappe
s på det sted, hvor 'x' normalt ville gå kaldes set-UID eller set-groupId flag (På et eksekverbart program med sæt-UID eller set-groupId, at programmet kører med tilladelserne til sin ejer / gruppe. På et bibliotek, det set-UID/set-groupID styrker filer og mapper oprettet inde til at arve brugeren / GROUP af rodbiblioteket).
For sikkerhed, bør tilladelserne indstillingerne for WordPress være 755 for mapper og 644 for filer. De fleste værter dog kræve, at alle processer fostret af en bruger til at have en unik identitet for at tilføje et andet niveau af sikkerhed. Så hvis WordPress eller et plugin opretter en fil eller mappe, vil den have et unikt ejer (og ofte gruppe), så den mappe med 755 vil ikke lade os oprette filer i det og den fil med 644 vil ikke lade os gemme ændringer til det. Så en ændring skal ske.
Det er her vi ramt "Your mileage may vary" område. Typiske WordPress installerer kun brug for wp-content/ bibliotek, der skal 777 (således at WordPress kan skabe den wp-contents/uploads/ mappe). Hvis din wp-content/uploads/ eksisterer allerede, du kan hoppe lige over og gøre wp-content/ 755. Hvis du har aktiveret Organiser mine uploads til måned og år-baserede mapper så sub-biblioteker skal kontrolleres så godt wp-content/uploads/2006/06 for eksempel), så du skal uploads/ at være 777, 2006/ at være 777 og 06/ at være 777. Hvis du bruger ImageManager plugin, skal du tjekke tilladelserne på wp-content/uploads/2006/06/.thumbs/ så godt!
Dette er en grund til jeg foreslår, at du slukker Organiser mine uploads til måned og år-baserede mapper, fordi du vil have et problem med tilladelser hver måned, når en ny mappe skal oprettes. Bare lad dem alle gå til / wp-content/uploads.
Nogle mennesker bruger editoren i admin for at ændre tema og plug-in-filer (Jeg anbefaler imod dette, medmindre du kan holde 644 på de filer, der redigeres der), opdager de har tilladelse til emner (som PHP, vil have andre legitimationsoplysninger på de fleste servere) og ændre deres filer til 666. Jeg er utryg ved dette. Og jeg har et crush på FileZilla. Ja, jeg har brug for at komme ud mere.
Hvis jeg ftp til mit websted med FileZilla og dobbelt-klik på en fil, åbnes det i mine foretrukne teksteditor (Edit: Indstillinger: File visning / redigering i FileZilla menu) og i et meget mere "behagelig" miljø, jeg kan foretage ændringer, gemme, og klik OK for at uploade den ændrede fil til serveren. Den anden fordel, at dette er, at den fil, der læses og skrives via ftp som fastholder min bruger / gruppe identitet, der giver mig mere sikkerhed og kontrol.
Hvis du har forslag til denne artikel, er du velkommen til at efterlade en kommentar ...
27 Brugere kommenterede "WordPress Fejlfinding: Tilladelser, CHMOD og stier, Oh My!"
Roo siger, Thanks, very helpful. Jeg var på udkig efter noget lignende dette.
Min ex girlfreind oprettet denne hjemmeside, og jeg har altid redigeret det, men pludselig EDIT-knappen på min skærm hjemmeside er væk? Jeg kan ikke få adgang til nogen redigere opions? Hvordan kan jeg få det tilbage, som min ex er tilgængelig? Jeg har brug for at skrive nye ting ASAP? Kan nogen hjælpe mig? Daryl
Indtil du finde ud af, hvorfor knappen 'Rediger' forsvundet, kan du altid prøve [yourdomainhere].com/fishing/wp-admin og at der skulle tvinge WP login-skærmen til at komme op.
Jeg har et problem med at downloade billeder til WP .. Så hvis jeg fik det rigtigt, så alle mine wp-content tilladelser skal være 644.
Edgars: Følgende er fra den præmis, at jeg synes passer til dig:
"Typisk WordPress installerer kun brug for wp-content / bibliotek, der skal 777 (således at WordPress kan skabe den wp-contents/uploads mappe). Hvis du har aktiveret Organiser mine uploads til måned og år-baserede mapper så de undermapper skal kontrolleres så godt (wp-content/uploads/2006/06 for eksempel). "
Enhver DIRECTORY WordPress er udpeget til at bruge kan være nødvendigt at 777.
Changinging tilstanden af den wp-content / mappe til 777, som er i vid udstrækning betragtes som usikker er et gennemgående tema i hele Wordpress. Men det er ikke helt korrekt, hvis du har shell adgang: Problemet er, at på en Linux boks, php-scripts kører som ingen andre end den mappe er ejet af brugeren, så ingen kan ikke skrive til det, medmindre det er chmod 777. En bedre løsning er at ændre ejerskabet af biblioteket, som ingen og derefter uploade bibliotek kan chmod 755 og alle mapper oprettet af Wordpress er også chmod 755.
I skallen cd til Wordpress rodmappen og derefter skrive og indtast:
chown ingen wp-content
Hvis du ikke har shell adgang, så spørg din webhost til at gøre det for dig.
Men hvis din server kører med phpsuexec aktiveret, php-scripts køres som en bruger, som også har skrive adgang til mapper, der ejes af brugeren. Så i dette tilfælde upload mappe kan chmod 755.
Det er uheldigt, at Shell adgang bliver mere og mere sjældne med regelmæssige hosting planer.
Og 777 på en moderne vært er ikke så farligt, som det kan lyde, er det stadig ville træffe visse proces / config mangler for at blive udnyttet, og da vi snakker om / uploads / Jeg er ikke så bekymret for nogen hacking image / zip-filer, jeg holder der.
Der er et grundlæggende spørgsmål om sikkerhed med fastsættelse af en fil, som "wp-config.php" til 644 i et fælles miljø: det giver mulighed for andre brugere om, at værten til at læse din database indstillinger, der er indeholdt i filen. De kan derefter bruge din database indstillinger og gøre, hvad de vil med din database data. Se denne tråd om WP fora for mere:
http://wordpress.org/support/topic/83831
EDIT: Hvad jeg forsømt at sige ovenstående er, at spørgsmål om sikkerhed gælder, hvis de udbyder tillader SSH-adgang til din konto.
Pizdin: Dette er simpelthen ikke sandt i de fleste moderne delte miljøer.
Men jeg sætter pris på linket, folk er velkomne til at komme til deres egne konklusioner; ')
Hej, jeg er bekymret med de 777 spørgsmål om wp-plugin/uploads /
Hvad hvis folk lægge nogle scripts til denne mappe, som når henrettet vil slette andre filer i andre mapper (eller gør nogle grimme ting)?
Hej Adi:
Deres bekymringer er gyldige. Afhængigt af værten det ofte bliver en balancegang mellem sikkerhed og brugervenlighed-brug.
Hvis jeg var nødt til at bruge 777 (eller 666 på filerne), så snart jeg var færdig med at foretage ændringer, jeg ville blive hårdt fristet til at skifte alt tilbage til 755/644. Og jeg har da jeg var vært med Network Solutions (som jeg ikke anbefale som en vært).
Det problem, der ofte ligger i, hvordan web-vært tildeler en identitet til de brugere, der logger ind via ftp / etc. and the identity given to processes spun from inside WP's admin interface (the PHP process(s)). Disse er som regel anderledes, og det er derfor, du kan se forskelle i adfærd, når du redigerer / slette / upload af filer med ftp / etc. og når de gør det inden for WP admin område ...
Min nuværende vært, site5.com behandler sikkerhedsspørgsmål anderledes, så jeg kan holde til 755 mapper og filer på 644 endnu ikke modtaget tilladelse fejl, når du bruger WP admin værktøjer.
På den anden side, som Pizdin påpeget ovenfor (med nogle værter), kan en anden bruger i stand til at læse min wp-config.php fil i min nuværende miljø. Dette vedrører ikke mig for meget (jeg holde backups og de fleste hackere vil ikke 'poop i deres egen kage «, så at sige), men jeg har ændret wp-config.php til 600.
thirstan siger, Jeg er i færd med at oprette en blog på en ny vært med mit eget domænenavn og har problemer med tilladelserne, dit indlæg synes at være præcis, hvad jeg leder efter, var jeg spekulerer på, om stillingen stadig er på tide, at de nuværende WP ?
Wow, det er en køre-om sætning 
tak,
thirstan
Thirstan: Ja, Hass noget virkelig ændret sig der.
Den version af WP er faktisk ligegyldigt, selv om værten miljø vil. Eksempel: På aplus.net (og Network Solutions), vil du opleve problemer med WP ikke at have "tilladelse" til at oprette mapper og filer. Men ligesom værter site5.com håndtere det anderledes, og du vil ikke mærke nogen af tilladelsen problemer, der opstår med WordPress / PHP processer oprette eller redigere filer.
Sam mange tak for dette. Jeg har kæmpet med 1and1 for den sidste uge, fordi de ikke kunne forklare mig, hvorfor det pludselig min e-handels-plugin ikke længere kunne oprette miniaturer af de billeder, vi uploade.
Jeg tror nu, jeg forstår og kan være i stand til at få kundeservice til rent faktisk at hjælpe mig. Jeg læser dit indlæg igen og citerer det i min e-mail, når jeg forstår det fuldt ud.
Tak igen.
Bedste løsning for dette er for manuelt at oprette din mappestruktur på forhånd. Den eneste grund til at kræve 777 er fordi wordpress behov for at oprette disse mapper. Men hvis de mapper, der allerede findes en strammere sæt tilladelser er muligt. Derfor oprette mapper til de næste par år (en mappe for hver måned), så chmod til 755 mapper og filer til 644. Nogle gange har jeg bemærket, at biblioteker behovet 775 afhængig af din vært.
Skål!
hej, jeg forsøgte at chmod wp-content 755 til 644, men resultatet altid bliver 764. nogen idé? tak
Tre ord: PHP fejlsikret tilstand.
Jeg var på jagt efter dette problem for en kunde i cirka en time. Den uploads mappe er ejet af Apache-brugeren, men et år eller måneder mapper Wordpress forsøgt at skabe i sammenbrudte uploads indtil jeg slukket PHP fejlsikret tilstand. Nu virker det som en chizzamp!
Cheers Sam. Lige stødte ind i dette problem og samtidig trækker en WordPress.com til. Org blog på en ny vært. Det er første gang jeg har haft til at ændre filtilladelser.
Tak,
Matt
woow stor post, vil det være meget nyttigt for mig. Tak for dette store stykke arbejde.
Jeg havde forsøgt at ændre tilladelse til at ændre stierne, men intet virkede.
Indtil Bard 's kommentar.
Jeg har ændret stien ved at fjerne den forreste skråstreg før wp-content/uploads ... og det virkede:)
Hej, er der ikke brug for at give tilladelse inde i serveren for dette. Bare logge ind i WP hjælp af admin legitimationsoplysninger og derefter gå til Indstillinger -> Diverse -> og derefter kopiere og indsætte standard sti vist der. Dette vil løse problemet, og jeg havde fastsat det lige nu ... :-) Det er så simpelt. Må ikke bang for meget for et simpelt spørgsmål.
Hilsen,
Rj.
Systems Engineer
actsupport.com
Tak RJ, men det er en smule mere kompliceret med nogle værter.
