I have looked around a great deal on the Drupal forum and elsewhere but I cannot yet resolve this.
I have had to reinstall a large, fully functional site (Drupal 7.18) onto a new server. This has gone very smoothly. However, I do not seem to be able to set permissions for my sites/default/files directory in a manner that keeps it accessible and safe when browsing using the IMCE file browser.
Usually I set sites/default/files (and subdirectories within it) as 755, with files within these directories as 664. This works well on many other Drupal 7 sites I have built.
HOWEVER in this case, with these permissions I get the message "Unable to get a working directory for the file browser".
Only by setting directory permissions as 777 can I browse the files in these directories using IMCE - and I know that is really bad practice on shared hosting.
Please can someone advise on troubleshooting this? I have spent hours but I am getting nowhere.
I wonder if the ownership of the files and directories themselves is wrong. If they are wrong, can anyone direct me to step-by-step instructions for changing them?
Examining the 'problem' files and directories using FireFTP, I see
that both user and group names are the same as the FTP username that
was given me by my web host.
Looking at another Drupal site that works properly, I see that files
and directories in sites/default/files are set to user 531/group 528.
Thanks in anticipation! I am running D7.18 on PHP 5.2.10 with extensions enabled. Everything else seems to be working very well indeed. However, I am not sure I have the Apache or Linux skills needed to resolve this, or even to ask my hosts the correct questions ...
755 basically means that only the owner of the files can modify them, so you could try changing the directory permissions to 775 so that the owner and group can modify.
If you are using shared hosting I suggest you ask your hosting provider to help as they will have a better understanding of the users and groups on the server.
Cheers
Related
I had a shared hosting package with 1and1 and I just moved over to their VPS hosting that uses Plesk. I already had the domains moved over the VPS server and I already uploaded all of the files via FTP.
I talked to an agent yesterday and he helped me setup the main page on the website so that it would go to the appropriate root directory. The main website is working properly whenever I go the main domain name, however, whenever I go to website.com/blank or website.com/stuff, I receive a 404 error.
The strange part is that I see the files in Plesk file manager, I just don't know why they are not displaying properly. I didn't change anything in the migration process.
I did not change the code on any of the pages and I have contacted their customer support team a number of times, but they have been unable to resolve the issue.
Can anyone tell me what I should do to make sure that the files are associated with the correct pages?
Have you checked the permission for the files and folder under your domain, this seems to be an issue with either your ownership or permission of the files. And if thats not the problem it could even be your .htaccess file.. make sure you have transferred your .htaccess file as well from old shared hosting to new VPS.
A month ago I purchased a domain & hosting. Besides dabbling in some HTML for fun a few years ago, I didn't have any experience in all this "technical stuff". After a month of "doing my homework", I'm still trying to figure out a few things and I haven't had much luck searching SO or Google...
I've really only been using Filezilla & Notepad up til this point - I've been trying to keep it simple. Browsing my server, I couldn't seem to find the file "httpd.conf" or "php.ini" (among other files & dirs). I've been dabbling in .htaccess as an alternative but I've hit a roadblock since not all configs go in .htaccess files.
I made a phpinfo() script. Within that info, it shows "/etc/php5/cgi/php.ini" - yet this directory isn't shown in filezilla.
I know I must be missing something - how do I back up, access this directory & edit those configuration files?
Thank you so much for your help & deepest apologies if I've made you facepalm :P
-adraedin
If you just purchase hosting (as opposed to a virtual server), you will not usually have access to system-wide configuration files like php.ini or the global httpd configuration directories.
Instead, you can perform a limited subset of configuration through .htaccess files in your directories.
The reason you don't see the configuration directories is that your FTP access only shows you your own directory, neither those of other users on your server, nor the system-wide configuration or other software that might be running there.
Your php.ini file is extremely important. It is highly unrecommended to edit this file unless you know what you're doing. The most likely reason you can't see it is because it is outside of your "privilege zone" (meaning its hidden by your hosting company). This is typically done so that you don't mess with other accounts and domains using the same server.
If you need a change something within the httpd.config or php.ini file, and you can't make the change in your .htaccess, usually you can contact your hosting company and they'll modify the file for you. It really just depends on what you're looking to change/modify/edit.
Most of the time, in regards to your hosting, you can only see your account/domain files. This keeps you restricted to a particular section of the hard drive so you don't start messing with other peoples files/configurations.
I've recently been tasked with moving a client out of a shared hosting environment into an AWS environment where all the infrastructure was hosted and supplied by Amazon. The client is running multiple (dated) Drupal instances, but luckily I've been able to move the environment over and have it function, except for the errors below.
I've discovered that Drupal is generating errors throughout their environment(s) on the AWS instance, but not on the shared hosting instance, despite using the same except code base/database.
Permission Error(s): http://i.imgur.com/cRQOo4W.jpg
Timezone Error(s): http://i.imgur.com/VFgWZKE.jpg
Personally, I'm not a big Drupal guy and I've researched the file permissions on the root directories (https://www.drupal.org/node/244924), but I honestly do not want to go around changing things without fully knowing the effect of a change.
If anyone can provide insight to the root of these errors and how I can potential resolve them, I would greatly appreciate it.
P.S. - Most of the environments in question are running on Drupal 6.33 (not 100% sure), but they do have one environment running on Drupal 7.23 (again, not 100% sure).
Make sure the web server's user/group owns the Drupal files, not root. Then follow the file permission instructions in INSTALL.txt.
Select a timezone in the Regional Settings of your Drupal site on AWS. If that doesn't do it, set the date.timezone in the php.ini file there.
The title doesn't really sum it all up...
I have recently installed ModX Revolution 2.2.4 on an Apache server and I am having complications with the cache folder. Occasionally I have to manually clear the cache folder via ftp, but any files written there are owned by Apache and my account can't delete them. I have tried adding the "new_file_permissions" and "new_folder_permissions" to the system settings, but there is no change. The cache files are always owned by Apache and I have no access via ftp.
Also, files such as the .htaccess and really anything I upload (css etc) are seen as uneditable to modx unless I manually change them to 777 via ftp. I can't change owner and group though.
The server tech can't figure it out. This has come up before on the modx forums but it has never been answered.
Obviously, this is a server problem.
I had this problem (with an IIS server though), and the host needed to change some of their settings.
Especially, if MODX works on your different host(s).
That is the way it is supposed to work, your FTP account does not have permission to write files written by apache, your ftp may be a member of the group but does not have write permission. [needed to delete]. I suspect this is by design for security purposes.
Your new_file_permissions, new_folder_permissions are used for the modx file manager.
So you can do a couple of things:
Run modx under fastcgi, that way the user writing the files should be the same user as the ftp user.
OR
write a little script [you can even stuff it in a snippet] that will delete the cache files for you. [since it will be running as the apache user, it should be no problem.
This is installed on a Unix system I don't have direct access to, but can get insight on by sitting with a network team.
The problem is this, I have 3 folders I need access to, read and write. The problem is, I only have access to 1 of them, and only read. This is via ColdFusion, I can get into them fine with the user they are assigned to (and the CF server runs on, which is the "www" user).
I CAN read and write to the temporary file directory, the place files are stored before they are moved to the destination directory (SERVER-INF/ etc etc etc), but that's not helpful. I have tried having the network people set the permissions for the other folders to the same thing, but with no results. The current settings of the folder I can access are rwxrws--- and the other folders are rwxrwxr-x, so I should have more permissions ( the "s" is not a mistake in the first folder).
We have tried setting the other folders to 777 and we did not even get read capability. Does the server need to be restarted on a Unix box after setting new permissions for ColdFusion to be able to get to them? I'm out of ideas right now, I'll take any new suggestions.
TL;DR
All using ColdFusion
temp directory - can read and write to
folder 1 - can read from (including subdirectories)
folder 2 - cannot read or write to (permission denied)
folder 3 - cannot read or write to (permission denied)
Goal: Get upload functionality working.
Edit: Server using apache
Just a random guess... Have you checked that paths you are trying to access are fully correct? They should be absolute for file operations, and www user must have X permissions on the all path directories -- to enter them.
The problem ended up being a restart was required after setting the new folder permissions. We didn't think this was an issue on a Unix box, however ColdFusion apparently did. This worked.