I keep seeing a 403 error for my stylesheet which is hosted on my Rasberry Pi (webserver). I ran ls -al and this is the result:
pi#raspberrypi ~/www $ ls -al
total 16
drwxr-xr-x 2 pi root 4096 Mar 17 20:18 .
drwxr-xr-x 12 root root 4096 Mar 15 16:44 ..
-rw-r--r-- 1 pi root 644 Mar 17 20:18 index.html
-rw------- 1 pi root 329 Mar 17 20:19 stylesheet.css
The index.html data shows up when I point my browser at the ip, but there is no formatting and whenever I try to acess the css file through looking at the source code it keeps telling me theres a 403 error :(
Can anyone help a brother out??
Cheers!
You need proper permissions for the www folder, and that depends on which webserver you are running. For apache on debian the user is www-data, if your webroot is ~/www and you are user pi try these commands
Change owner to apache user recursively
Change Permissions to read for all recursively
chown -R www-data:www-data /home/pi/www
chmod -R 644 /home/pi/www
Related
I am planning to use Wordpress official docker image on Amazon ECS. The problem is that instead working on the root path https://www.example.com/, I need it to work on a subdirectory path https://www.example.com/blog/.
To modify this I am planning to create a new Docker image based on the official Wordpress docker image.
My current Dockerfile looks like this.
FROM wordpress:6.0.1-apache
# Copying to premium so user can access it through
# domain/blog
RUN cd /var/www/html; \
mkdir blog; \
cp !\(blog\) blog; \
# We copy the wordpress instance to subdirectory and disable
# access to the root instance.
echo "Hello World!" > /var/www/html/index.php;
However this doesn't work. When I access https://www.example.com/blog it shows Forbidden.
The log shows this
[autoindex:error] [pid 23] [client 172.30.0.1:61822] AH01276: Cannot serve directory /var/www/html/blog/: No matching DirectoryIndex (index.php,index.html) found, and server-generated directory index forbidden by Options directive
It seems that the image does not copy the wordpress library.
wordpress % docker compose exec wordpress bash
root#63d417de7f31:/var/www/html# ls
index.php blog wp-config.php wp-content
root#63d417de7f31:/var/www/html# ls -al
total 32
drwxrwxrwx 4 www-data www-data 4096 Aug 5 06:13 .
drwxr-xr-x 1 root root 4096 Aug 2 07:49 ..
-rw-r--r-- 1 root root 13 Aug 5 06:06 index.php
drwxr-xr-x 2 root root 4096 Aug 5 06:06 blog
-rw-r--r-- 1 www-data www-data 5584 Aug 5 06:13 wp-config.php
drwxrwxrwx 5 www-data www-data 4096 Aug 5 06:13 wp-content
root#63d417de7f31:/var/www/html# ls -al blog/
total 8
drwxr-xr-x 2 root root 4096 Aug 5 06:06 .
drwxrwxrwx 4 www-data www-data 4096 Aug 5 06:13 ..
root#63d417de7f31:/var/www/html# exit
What should I do?
Update 1
When I trim the Dockerfile to just the base image like this,
FROM wordpress:6.0.1-apache
the wordpress files are copied into /var/www/html.
% docker compose exec wordpress bash
root#f9ad22323268:/var/www/html# ls
index.php wp-admin wp-config-sample.php wp-includes wp-mail.php xmlrpc.php
license.txt wp-blog-header.php wp-config.php wp-links-opml.php wp-settings.php
readme.html wp-comments-post.php wp-content wp-load.php wp-signup.php
wp-activate.php wp-config-docker.php wp-cron.php wp-login.php wp-trackback.php
Update 2
I tried using this
FROM wordpress:6.0.1-apache
WORKDIR /var/www/html/blog
This copies the Wordpress installation both in /var/www/html and /var/www/html/blog. This still fits the requirement, however I want to remove the one in /var/www/html/. I tried rewriting to /var/www/html/index.php like below
FROM wordpress:6.0.1-apache
WORKDIR /var/www/html/blog
RUN echo "Hello World!" > /var/www/html/index.php
But it's not rewritten. Seems like it's being rewritten from the entrypoint
https://github.com/docker-library/wordpress/blob/master/docker-entrypoint.sh
Give Apache user access to blog directory. By adding following to Dockerfile
RUN chown -R www-data:www-data /var/www/html/blog
I'm trying to change the user: root to www-data in Dockerfile to build wordpress image. Once I run the dockerfile and go inside the image: the permission is not changed.
This is my Dockerfile:
FROM wordpress:php7.1-apache
COPY . /var/www/html
WORKDIR /var/www/html
RUN chown -R www-data:www-data /var/www/html/
RUN chmod -R 777 /var/www/html
This is the result in the image by running that Dockerfie:
root#081507c3824e:/var/www/html# ls -lh
total 228K
-rw-r--r-- 1 root root 149 Jul 5 05:09 Dockerfile
-rw-r--r-- 1 root root 405 Jul 5 05:09 index.php
-rw-r--r-- 1 root root 20K Jul 5 05:09 license.txt
-rw-r--r-- 1 root root 7.2K Jul 5 05:09 readme.html
drwxr-xr-x 9 root root 4.0K Jul 5 05:15 wp-admin
-rw-r--r-- 1 root root 351 Jul 5 05:09 wp-blog-header.php
/var/www/html is marked a VOLUME in Dockerfile of wordpress. Your RUN instruction won't persist after the build.
You can try any of the following approaches if you want to change the permisions of /var/www/html/ directory.
You can mount a directory with modified permissions from host machine into the container.
You can create an entrypoint script which changes the permission of the directory before starting the main process.
I've setup a new symfony 4 project. This is running on vagrant for local development. Now I'm running into file permission issues.
Symfony itself says it should be any problem: Setting up or Fixing File Permissions.
If I run bin/console cache:clear, the code is running fine. But once I change my code, I'm getting the following error:
(1/1) IOException
Unable to write to the "/var/www/path_to_project/var/cache/dev" directory.
Running bin/console cache:clear again, code works fine. But changing the code again, same write issue again.
I tried to chmod +r 777 var/cache/dev, but that doesn't change a thing. How can I fix this?
Output for Ahmed bhs
$ ls -la var/
total 16
drwxrwxr-x 4 vagrant vagrant 136 Jan 7 11:41 ./
drwxrwxr-x 14 vagrant vagrant 476 Jan 7 12:30 ../
drwxrwxr-x 3 vagrant vagrant 102 Jan 7 12:57 cache/
drwxrwxr-x 2 vagrant vagrant 68 Jan 7 11:41 log/
$ id
uid=1000(vagrant) gid=1000(vagrant) groups=1000(vagrant),4(adm),24(cdrom),27(sudo),30(dip),33(www-data),46(plugdev),110(lxd),115(lpadmin),116(sambashare),998(rvm),1003(www-user)
EDIT
The problem wasn't symfony but the configuration of my vagrantfile.
Synced_folder had owner 'vagrant' while apache 'www-data'. Made all 'www-data' and now it is working fine. Totally not symfony related!
Try
sudo chmod -R 777 /var/www/path_to_project/var/cache/*
Run chmod -R 0777 var instead of running commands for separate folders.
I have a strange issue on my debian vm.
I have a nginx directory like that.
$ ll
total 9076
-rw-r----- 1 www-data adm 330645 juil. 13 10:40 access.log
-rw-r--r-- 1 www-data root 143902 juil. 12 01:08 access.log.1
-rw-r----- 1 www-data adm 852976 juil. 13 10:41 error.log
I try to read the access.log with the foo user.
So, I have added this user to adm group.
$ cat /etc/group | grep adm
adm:x:4:admin,foo
But the user can't read the file. I have tried to add the user to www-data group, but the problem is the same. Do you know what is the problem ?
I thought know how user/group works, it seems not :)
BR,
Eric
To read a file, the user needs execute privileges to all of the parent directories. If your logs are in /var/log/nginx make sure the foo user or one of its groups has x access to each directory (/var, /var/log/, /var/log/nginx) of whatever path logs are in.
I am working on Solaris 10 machine. In that i cannot able to untar my file. Logs are given below. Anyone please suggest what may be the issue? I can able to create tar file but unable to untar. :(
bash-3.2# ls -lrth ConfigCheck-120614-KL.out*
-rw-r--r-- 1 root root 144K Jun 12 17:15 ConfigCheck-120614-KL.out
-rwxrwxrwx 1 root root 146K Jun 16 16:49 ConfigCheck-120614-KL.out.tar
bash-3.2# tar xvf ConfigCheck-120614-KL.out.tar
tar: extract not authorized
bash-3.2# tar tvf ConfigCheck-120614-KL.out.tar
-rw-r--r-- 0/0 147377 Jun 12 17:15 2014 ConfigCheck-120614-KL.out
Solaris 11 tar will fail with that error message if you are running as uid 0 but do not have the Media Restore profile set up in the RBAC configuration.
Unless you're trying to restore from backup, you should normally be untarring files as a normal user, not root, to avoid accidentally overwriting critical system files.