Ändra rättigheter på filer i html-mappen Ubuntu-server

Ni kan inte bara köra "sudo chmod 777 *" i mappen?

-R flaggan står för recursive, och ändrar allt, filer undermappar och filer i undermappar. Gäller för både chmod chown och chgrp. Precis som dopedog skriver.

chmod g+s /var/www/mapp borde vara en bra lösning för att låta er ladda upp filer utan att ni behöver ändra rättigheterna på filen efter det.
Det finns många olika sätt att lösa det på, och det hela beror på vilka rättigheter filerna behöver ha för funktionaliteten i hemsidan/webappen. Och sedan hur viktigt säkerheten är.
Läs exempelvis detta när du har tid:
http://serverfault.com/questions/357108/what-permissions-shou...

antar att det är för sent nu, men gör aldrig detta. ALDRIG.

här är ett tips för filer respektive mappar
http://superuser.com/questions/91935/how-to-chmod-all-directo...

Loggen från FTP-servern säger antagligen mer än loggen från klienten. Men antagligen har du gjort något fel med rättigheterna, så att kontot eller grupp-kontot som FTP-servern använder har skriv-rättigheter till befintliga filer, men inte skriv-rättigheter till html-mappen, och eventuellt dess undermappar.

Vad exakt har du gjort, så blir det mindre gissningar? "Detta är nu ändrat till det Genesis skrev" beskriver inte vad du gjort. Jag länkade till en guide som skrev flera olika alternativ för flera olika scenarion.

Vilken användare och grupp äger html-mappen i /var/www, och vad är chmod-rättigheterna dit? (Visa oss "ln -l /var/www/html" om du inte vet)

Vilken FTP-server använder du? vsftpd? Kör du med riktiga systemanvändare till FTP-servern, eller har du satt upp virtuella användare som inte är riktiga systemanvändare?
Har du modifierad något med systemgrupperna, så att systemanvändaren som FTP-servern laddar upp filer via är medlem i flera olika grupper?

Använder hemsidan någon forma av upload eller på något sätt behöver modifiera några filer lokalt på servern? Eller är den helt statisk, och det är bara ni via FTP-servern som behöver skriv-rättigheter till något i /var/www?

Avslutar man med `+` i stället för `\;` så blir det bara en (eller tja, minimalt antal) körningar av `chmod` per sökning (om vi har GNU find, vill säga — se `-exec command {} +` i `man find`).

I vilket fall så kan man använda `chmod`s symboliska läge för att förenkla detta till ett enda kommando, då det erbjuder `X` som betyder "exekverbart, men bara om det är en katalog". Dessutom har `chmod` en egen växel `-R` för att vandra rekursivt i katalogstrukturen, så ovanstående kommandon är i funktion ekvivalent med:

chmod -R a=rX,u+w .

(Faktiskt är det "bättre" än `find`-konstruktionen i hänsynen att rättigheter för målen för de symboliska länkar som träffas på inte ändras, då `chmod -R` sonika hoppar över symboliska länkar.)

Det är dock försvinnande sällan som ett sådant kommando ska behöva köras, och om det behöver göras ofta så bör man kolla upp varför och ändra sina arbetsmönster.

Det är få saker som kan vara så destruktiva för ett *nix-system som att rekursivt braka på med rättighetsförändringar (jag brukar säga att det är enda tillfället då jag rekommenderar att bara rensa och installera om hela systemet snarare än att försöka "laga" det i efterhand). Det är alltför vanligt att personer som är nya till rättighetssystemet tror att det är en busbra lösning att köra 777 rekursivt från roten (sedan länge så krävs `--no-preserve-root` för detta, men det är ett litet hinder att ta sig över om man verkligen vill ), för att sedan märka att systemet är totalt rökt. Tips om att köra `chmod` rekursivt över stora mängder filer bör ges med stor blinkande varningstext.

Rättigheter är ett härke i Linux. Speciellt om man är flera användare som ska ändra i samma filer. På de flesta serverar lägger jag till ett script som sätter önskade rättigheter på alla filer. Då är det bara att köra chmod.sh . när det skiter sig . Vilket är ganska ofta.

Det är rätt horribelt . Försök lista ut varför det uppstår filer med "fel" (stora citationstecken) rättigheter/ägare till att börja med, och lös det korrekt från början i stället.