I have moved a Magento from one server to another.
Now images are broken when Magento creates the thumbnails. If I chenged the permissions to 777 for folders and 644 for files via FTP, everythig is fine, but the next image that is generated is wrong again.
I have checked the uploader.php file, but the permission set in the code is correct.
What could be the problem?
Check the files owner. Maybe the web-server users are different from server1 and server2, and when magento creates the new images, the permission fails.
If i remember correctly, magento expects the web-server user to own the project assets, you could try to change the file ownership:
chown -R your-weserver-user:your-webserver-user-group /your/magento/app/assets_folder
also, check this other thread: https://magento.stackexchange.com/questions/99646/image-uploads-using-wrong-permissions
Related
After I've updated to Mediawiki 1.29.0, I can't upload any file. When I upload a file, I get this error message:
Could not open lock file for "mwstore://local-backend/local-public/b/b0/1.jpg".
I've chmod the folder images and sub-directories to 755, and verified that the folder images/b/b0 is found and writable.
I'm running on Centos 7.5 and PHP 5.6
Solved by changing images folder permissions to 777 instead of 755
I had the exact same message
Could not open lock file etc
In my LocalSettings.php I commented out $wgUploadDirectory , that according to the documentation at mediawiki documenation for $wgUploadDirectory will make it necessary to also redefine $wgUploadPath
There are other variables which are defined relative to this one. If you redefine this in your LocalSettings.php then all dependent variables including $wgUploadPath will need redefining also. If both these settings are not coherent the files will be uploaded to different folder ($wgUploadDirectory) than from where MediaWiki will try to retrieve it for viewing ($wgUploadPath)!
After commenting out $wgUploadDirectory I could upload and use files.
I moved the complete yii2 installation from one server to another with the help of FileZilla. Sadly, Filezilla don't keep the file permissions by default, and now I'm facing issues with file / directory permissions. I would like to know what's the file permissions for different directories and files in the yii2 directory hierarchy.
You should not transfer the project this way.
Currently it's the era of version control (especially Git) and Composer.
Once you created you project locally and put it under version control, you push it to your main repository and then deploy it to production server.
No need to use Filezilla or something like that.
If your hoster limits you in that, it's better to switch to another one.
In your current situation comparing and setting permissions manually can be very tidious, some of the permissions are set during init command.
So I recommend to deploy it again using version control and Composer instead of struggling with manual permissions setting.
But just in case, I checked production server, most of the folder permissions are 0755, for files - 0644. Folders like runtime, assets have 0777 permissions and set with init command as I mentioned above.
Locally I use Vagrant and pretty much everything here has 0777 permission.
I've been following the Fortrabbit's guide to install phpMyAdmin.
I've managed to put the folder in my htdocs, but from what I read I must actually upload it into the app root below htdocs. Problem is the app root has write protection and I can't seem to change permissions via SFTP.
Any solutions?
Edit
Solved. I had my Root Path under settings set to htdocs/public, so I couldn't hit the phpMyAdmin folder. Setting the Root Path back to htdocs/ enabled me to access it like normal.
Where did you read it must go to the app root? I don't see that in the tutorial, but admit I may have missed it. Also, I'm not clear what you mean by "app root".
Note that in this case, there are three different 'root' folders, be careful not to get confused.
The file system root, /. All the files on your server live here. Depending how fortrabbit configures their system, you may not even have access to this.
The web folder root. Files in this folder and below are available online through your webserver.
The SFTP root. This also depends on how fortrabbit configures their server, it could be your web root, the file system root, or your home directory. You may be able to change to other folders, or maybe not.
Normally, htdocs is the root or base folder where your webserver is looking for files to serve. It isn't clear from my browsing the fortrabbit site if they do anything odd with their configuration, so this is a close approximation for what most servers look like. For the sake of illustration, we'll pretend that htdocs is in /var but it can be anywhere on disk.
So the file system might look a bit like:
/
/bin/
/etc/
/home/MichaelHanslo/
/home/MichaelHanslo/budget_presentation.odf
/var/
/var/htdocs/
/var/htdocs/index.html
/var/htdocs/pma/
/var/htdocs/calendar/
/var/htdocs/calendar/modify.php
/var/logs/
So in that scenario, going to http://example.com/ loads the file /var/htdocs/index.html, going to http://example.com/calendar/modify.php loads /var/htdocs/calendar/modify.php. So in most cases, you want to create a folder under htdocs for phpMyAdmin; you can call it anything you want (in my example above, I used 'pma'). Anyway, if you don't have permission to create the folder under your web root, then you should definitely ask your host for help, because something isn't right.
Hope that helps clear it up for you.
I logged in fine, as I can browse the directories fine and open the files, but when I go to save I get a permission denied error. What am I doing wrong?
Maybe simply you don't have the permission to write to the directory.
Mac or PC? I had the same problem on OSX when using SFTP with XAMPP built in FTP server (so i could update local files instead of remote).
Try modifying the permissions on your XAMPP folder (CMD + I) and set EVERYONE to READ/WRITE. Then click the cog (gear icon) and choose apply. This will apply the permissions to all subfolders as well.
Try uploading your files again and see if you still get permission denied errors.
If doing this for a remote server, you'll have to make sure your SFTP user account is listed within an allowed group or is owner of files on your server.
Hope this helps.
Yes, make sure you have write permissions. The easiest way to check and update is the follwing:
ls -al see which permissions are on your file
sudo chmod 777 file_name give permissions to desired file
See more about establishing permissions for an entire group of files http://www.rackspace.com/knowledge_center/article/how-to-add-linux-user-with-document-root-permissions
Take two steps:
check your server permission
make sure you local sftp-config.json
{
"type": "sftp", // not ftp if port is default
}
I have developed a download/upload manager script.
When I upload a file via POST method it is stored in a folder called files, the files folder is within another folder called download-manager.
Now it seems when I upload via the POST method 0666 CHMOD works when I want to rename, delete the file but the download-manager folder and the files folder need to be 0777 CHMOD for this to work. Now can someone tell me if this is dangerous?
1) I got a deny all in .htaccess so nobody can access the files directory via a browser
2) the upload script is protected by a username and password which the person who uses the script will obviously change, so only admins can basically upload, rename, edit, delete files and the records in the MySQL database.
When a file is uploaded a record is added to the database with information like file type, file name, file size etc and then the unique id (auto incremented by MySQL) is appended to the process.php file which gets the file from the directory and mime type etc that is not revealed, the process.php basically does the checks to see if record and files exists and if so forces the download of that file.
Basically the download URL is like: wwww.mydomain.com/process.php?file=57, a check is done to obviously make sure that id exists in the database and that a file exists with the file name stored in the database with that id.
Now all this works fine when uploading the file via a form using POST method but I also added a manual upload so for people who want to upload a file that is larger than the size their webhost allows they can simply upload the file via a FTP program for example and then just add the filename and file details manually themselves via a form in the admin area to link the record with the file. The problem is then a permission issue because if the file is uploaded via FTP or whatever way they upload the file by the php script cannot rename, delete the file if needed in the future as the php script does not have the correct privileges. So from what I gather, the only option is then telling the persons who use the script to change the file chmod to 0777 for it to work, i think that will make it work?
But then I have the problem of 0777 also being executable. The script allows any file type upload as it's a download/upload manager script but at the same time I am slightly confused with all this permissions lark and what I should actually be doing. As php is limited by the max upload size set by a host I want to add manual upload so users can upload the file by another method and assign the file to the database record but then as stated I get a problem when wanting to rename, delete the file via the php script.
I have developed the script to detect such problems and notify the user etc but I would like to try and make this script do all the leg work or nearly all of it without having to state in the manual that the admin will have to chmod the file to 0777 when they want the script to rename, delete the file, although I don't know if just chmodding the file to 0777 will actually allow the php script to the rename, delete it and so forth but also security is then a concern.
UPDATED
Ok thanks so chown the file before chmodding it on upload?
Do i just use chown() around the file and nothing else and that will make it owned by the server process and make it private? as i see you got
chown apache:apache '/path/to/files' ;
Do I need to add the apache:apache bit?
I did think of this as simpler solution, if a admin does a manual upload tell them they will have to rename/delete the file manually if needed in the future because the script won't have the correct permissions to do so, this would then make this a easy solution, as the manualupload script can just rename the db record to keep it linked to the file. That way no worries of file permission issues.
Simply put user changes file manually via ftp for example from myfile.zip to somefile.zip then they edit the db record for that file and change the filename to somefile.zip from the old filename myfile.zip, that way everything is linked still but no worries about permission issues. As I also have been reading that chown() does not always work or cannot be relied on for whatever reason.
1) i got a deny all in .htaccess so nobody can access the files directory via a browser
Store your files in a separate folder, away from the directory structure that houses your PHP files.
As far as the permissions on the directory are concerned, there are three ways to go about setting up the permissions on the folder:
Make it world-writable (chmod 0777 '/path/to/files/')
This is not recommended, as it has major security implications especially on a non-dedicated server; anyone who has an account or can tell a process on the server to write/delete to that folder will be able to change its contents.
Make it temporary (chmod 1777 '/path/to/files/')
This also carries a security concern, but less so than option 1 for the following reason: users cannot modify the directory--only the files they own.
Make it owned by the server process and make it private (chown apache:apache '/path/to/files' ; chmod 0700 '/path/to/files')
This is arguably the best solution.
Just relax & enjoy.
On many shared hostings it's the only possible solution anyway.
There is another option - to ask a user for ftp pass and use ftp for copying files from tmp, like wordpress does. But I think it's even less secure.