I have a problem whith my installation of docker. When I launch my docker-compose up I have this error :
front_1 | /var/lock/apache2 already exists but is not a directory owned by www-data.
front_1 | Please fix manually. Aborting.
I have this error because I add this line in my dockerfile conf :
RUN usermod -u 1000 www-data
But if I delete this line, my symfony project doesn't work with docker.
Do you have any ideas to solve my problem ?
Best regards
As I see it, you are trying to change UID of user www-data inside docker to have the same ID as host machine user UID (you), so you can open project files in your IDE.
This introduces file permissions problems on apache2 service, which can't read it's own files (config, pid,...), simply because it is not the same user anymore.
Quick 'dirty' solution is to change only owner of symfony project files to UID 1000, but keep group (GID) to the www-data. This applies only for dev machine. Else you don't needed it. Run command inside container.
chown -R 1000:www-data /home/project
You can create some bash alias inside docker to have it at hand.
Other option is to use ACL which will set existing files and folder with permissions, which will get inherited to newly created files under given folder. This could be put to bootstrap script inside container. But only for DEV mode. This way you won't need to run chown.
chown -R 1000:www-data /home/project #set for existing files
/usr/bin/setfacl -R -m u:www-data:rwx -m u:0:rwx -m u:1000:rwx /home/project
/usr/bin/setfacl -dR -m u:www-data:rwx -m u:0:rwx -m u:1000:rwx /home/project
Each -m is for a different user. First is www-data (apache2), second is 0 (root) and third is 1000 (you).
Remember UID can change anytime. So this could create security hole if mentioned users are not having proper UID.
I used second method only for folders, where PHP via apache2 sets permissions (uploaded files, cache,...), but host user needs to access these files.
Related
Our web development setup on Ubuntu 20.04 looks as follows:
We run Apache as www-data (pretty standard)
The user logs in as "dev" (for example)
So PHPStorm runs as dev
This usually leeds to the problem, that CLI commands (such as building the Theme) and actions via the web interface (such as changing Theme colors in the Admin Panel) clash with file permissions when for example the CLI creates a file which Apache later tries to change.
For years (i.e. with Magento 2, Contao, Laravel, ... before we started working with Shopware 6) we went well with the following command in the projects folder, using Linux ACLs:
export FOLDER=projects && sudo setfacl -Rm u:$USER:rwx $FOLDER && sudo setfacl -Rm u:www-data:rwx $FOLDER && sudo setfacl -Rm d:u:$USER:rwx $FOLDER && sudo setfacl -Rm d:u:www-data:rwx $FOLDER && sudo chmod 600 config
So ACLs are set properly and access works for the webserver as well as CLI commands .
And then came Shopware.
When building or changing the theme, the underlying Flysystem tries to set the visibility of files (the permissions). And while you can read/write files properly with the setfacl trick above, chmod is only possible for the file owner (which is "dev").
So we are getting:
detail: "Warning: chmod(): Operation not permitted"
meta: {trace: [,…], file:
"/home/dev/projects/example.com/vendor/league/flysystem/src/Adapter/Local.php",
We are wondering what is an elegant solution for this? How are others solving this?
Approaches we are considering:
letting apache run under the same user as the logged in user
doing CLI tasks as www-data
switching to docker and also use www-data scope for everything
We decided to run Apache and FPM processed unter the logged in user. To avoid security issues, Apache should first be bound to 127.0.0.1:
in /etc/apache2/ports.conf
Listen 127.0.0.1:80
Listen ::1:80
<IfModule ssl_module>
Listen 127.0.0.1:443
Listen ::1:443
</IfModule>
Next, in /etc/apache2/envvars we set the variables APACHE_RUN_USER and APACHE_RUN_GROUP to the logged in user dev.
For FPM we set in all /etc/php/*/fpm/pool.d/www.conf
user = dev
group = dev
listen.owner = dev
listen.group = dev
Finally we restart apache and FPM processed and make sure the project files are owned by the logged in user.
You also might want to delete old sessions of the www-data user (or chown them)
sudo rm /var/lib/php/sessions/*
I have a Joomla site that the files is owner by root:root. But this way I can't update or install any plugins on Joomla. However when I set de folder's site to the apache owner the site downs return ERROR 500.
How could I fix it?
I've tried set apache owner end set the permissions like below:
chown apache:apache /var/www/html/site
chmod -R 755 /var/www/html/site
Ps.: The site was migrated from another server where the owner of the files is the apache.
Simply run apachectl -S as root or sudo (sudo apachectl -S) and look at the lines which tell User and Group owner.
Other solution, typing the command ps faux will tell you what you need at first column the owner of the process you want to know about.
Also, htop command could help you as same as before if it is installed.
EDIT :
you can also specify -R to do recursive with chown command
I found out the solution. Was just the permissions on files the problem. I don't know why, but when I moved the files of site to another server the folders change the permissions 755 to 655. Changed this permissions everything cames back to normal.
Thanks again!
I recently set up Lamp stack on ubuntu 14.04 for my web server. I'm working through Digital Ocean. These are the steps I went through...
On local machine I logged in to my web server with
sftp user#web_server_ip
Then
sftp> cd /var/www/html
How would I go upon getting onto my local machine to get the file for the site? And how would I transfer them?
I know that I have to use the [get] and [put] commands
I'm just confused what's considered local/remote? if I'm logged into the remote server on my local machine. Overthinking it?
This is the tutorial I'm trying to follow: How To Use SFTP to Securely Transfer Files with a Remote Server
Edit:
So I tried moving a whole directory from my local machine and this is what I ended up doing
scp -r /path/directory_name name#ip_address:/var/www/html
scp: /var/www/html/portfolio.take7: Permission denied
Should I be changing permission by using sudo prior to scp -r?
Edit2:
I have also tried
Where_directory_is$ scp -r /path/directory_name name#ip_address:/var/www/html
/var/www/html: No such file or directory
It might be easier to start with SCP which allows you to copy files with one command. So for example, if you had a local file /path/filename.css and wanted to transfer it to your server, you could use the following command on your local machine:
scp /path/filename.css username#remote_hostname_or_IP:~
This command copies the local file and transfers it to the home directory of the username on the remote server using SSH. You can then SSH in (ssh username#remote_hostname_or_IP) and then do what you need with the file sitting in your home directory, such as move it to the proper Apache directory.
Once you start to get more comfortable, you can switch to sftp if you like.
Update
Here is how to set up your Apache permissions. Let's say you have an account you on the linux computer running Apache, and we'll say the IP is 192.168.1.100.
On your local machine, create this shell script, secure.sh, and remember shell scripts need to have execute privileges (chmod +x secure.sh). Fill it with the following contents:
#!/usr/bin/env bash
# Lockdown the public web files
find /var/www -exec chown you:www-data {} \;
find /var/www -type d -exec chmod -v 750 {} \;
find /var/www -type f -exec chmod -v 640 {} \;
This shell script is setting the permissions for anything in the /var/www/ directory to be 750 for the directories and 640 for the files. This gives you complete read/write permissions for the files and www-data (which is the account for Apache) read permissions. Run this anytime you have uploaded files to ensure the permissions are always set correctly.
Next, SSH into your remote computer and go to the /var/www/html directory. Ensure that the ownership is not set to root. If it is, scp the secure.sh file into your remote computer, become root and run it. This only needs to be done once, so you can remotely set the permissions.
Now you can copy directly to /var/www/ through the scp -r command on your local computer from the top of the directory you wish to copy to /var/www/html:
scp -r ./ you#192.168.1.100:/var/www/html/
Then run this command to remotely run the secure.sh shell script and send the output to out.txt:
ssh you#192.168.1.100 -p 23815 ./secure.sh > out.txt
Then cat out.txt to see that the file permissions changed accordingly.
If this is a public facing computer, then you must add an SSH key to your scp connection. You can use this tutorial to find out more about generating your own keys, it is quite easy. To use the key, you only need to add -i private_key_file to your scp and ssh commands. Lastly, it would actually be safer to keep the /var/www files as root, SSH into the computer, su to become root, then run secure.sh as root (with the owner changed to root in the shell script). It all depends on the level of security you need to worry about. If it is a development computer (which is what I am assuming) no worries then.
For folders use
scp -r root#yourIp:/home/path/ /pathOfDirectory/
For files
scp -r root#yourIp:/home/path/ /pathOfDirectory/file fileNameCopied
I uploaded ajaxplorer "pydio-core-5.0.4.zip" to my server and after I extracted files into a folder in the server i request the folder to starting install but i get this message :
"Impossible write into the AJXP_DATA_PATH folder: Make sure to grant write access to this folder for your webserver!"
i made the folder : /data permissions to 777 and it did not make change ..
any solve ?
I'v got the same problem few hours ago.
The problem:
You put full permissions (777) to the data folder, but subfolders don't get it.
The solution:
sudo chmod -R 777 data
sudo chmod -R 777 data
or
sudo mkdir -m 777 your_pydio_path/data/tmp/sessions
I know this is old, but I was having the same issue with pydio-core-6.0.8. Also, I'm going to preface this by saying that I am a php noob. But I was able to resolve my issue without a chmod 777 command. Instead, I made the nginx user the owner of the data directory.
chown -R nginx /path/to/pydio-core-6.0.8/data
And then made sure that php-fpm was running as the nginx user with the two php-fpm.conf settings
listen.owner = nginx
user = nginx
After restarting php-fpm, I was able to load the pydio page which went into the startup wizard.
This command is so easy! But it's dangerous!
Go to /var/www/pydio for apache2 or /usr/share/nginx/html/pydio for nginx and try:
chmod ugo+x data
It's more protected!
I have set up a Linux Server and installed Apache and SVN and dav_svn on it. Now, when I try to upload to https://x.x.x.x:x/svn/repo with Tortoise SVN I get
Can't open file '/server/svn/repo/db/txn-current-lock': Permission denied
I have Set up my SSL correctly (I can checkout, no problems, even remotely due to Port Forwarding).
I'm guessing this has to do with the Linux Ownership of the Repository folders, How must I set this/ what are the commands?
This is a common problem. You're almost certainly running into permissions issues. To solve it, make sure that the apache user has read/write access to your entire repository. To do that, chown -R apache:apache *, chmod -R 664 * for everything under your svn repository.
Also, see here and here if you're still stuck.
Update to answer OP's additional question in comments:
The "664" string is an octal (base 8) representation of the permissions. There are three digits here, representing permissions for the owner, group, and everyone else (sometimes called "world"), respectively, for that file or directory.
Notice that each base 8 digit can be represented with 3 bits (000 for '0' through 111 for '7'). Each bit means something:
first bit: read permissions
second bit: write permissions
third bit: execute permissions
For example, 764 on a file would mean that:
the owner (first digit) has read/write/execute (7) permission
the group (second digit) has read/write (6) permission
everyone else (third digit) has read (4) permission
Hope that clears things up!
It's permission problem. It is not "classic" read/write permissions of apache user, but selinux one.
Apache cannot write to files labeled as httpd_sys_content_t they can be only read by apache.
You have 2 possibilities:
label svn repository files as httpd_sys_content_rw_t:
chcon -R -t httpd_sys_content_rw_t /path/to/your/svn/repo
set selinux boolean httpd_unified --> on
setsebool -P httpd_unified=1
I prefer 2nd possibility. You can play also with other selinux booleans connected with httpd:
getsebool -a | grep httpd
I also had this problem recently, and it was the SELinux which caused it.
I was trying to have the post-commit of subversion to notify Jenkins that the code has change so Jenkins would do a build and deploy to Nexus.
I had to do the following to get it to work.
1) First I checked if SELinux is enabled:
less /selinux/enforce
This will output 1 (for on) or 0 (for off)
2) Temporary disable SELinux:
echo 0 > /selinux/enforce
Now test see if it works now.
3) Enable SELinux:
echo 1 > /selinux/enforce
Change the policy for SELinux.
4) First view the current configuration:
/usr/sbin/getsebool -a | grep httpd
This will give you: httpd_can_network_connect --> off
5) Set this to on and your post-commit will work with SELinux:
/usr/sbin/setsebool -P httpd_can_network_connect on
Now it should be working again.
for example on debian
sudo gpasswd -a svn-admin www-data
sudo chgrp -R www-data svn/
sudo chmod -R g=rwsx svn/
I just had this problem
Having multiple user using the same repo caused the problem
Logout evey other user using the repo
Hope this helps
In addition to the repository permissions, the /tmp directory must also be writeable by all users.
3 Steps you can follow
chmod -R 775 <repo path>
---> change permissions of repository
chown -R apache:apache <repo path>
---> change owner of svn repository
chcon -R -t httpd_sys_content_t <repo path>
----> change SELinux security context of the svn repository
Try to disable SELinux by this command /usr/sbin/setenforce 0. In my case it solved the problem.