Awful permissions problems

Ramanonos's picture

I've been trying to install open atrium for at least 6 hours and cannot find a solution. There seems to be a permissions problem... Here's where I'm at:

I successfully installed a Ubuntu VM, and installed Drupal6. I then downloaded open atrium, copied it's contents into the example.php folder. I then went to the default folder and changed the settings.default file to settings.php, etc. i also created a files folder in the default folder. I went through the initial open Atrium installation BUT. It gave me these messages:

Requirements problemThe following error must be resolved before you can continue the installation process:The directory sites/default/files is not writable. An automated attempt to create this directory failed, possibly due to a permissions problem. To proceed with the installation, either create the directory and modify its permissions manually, or ensure that the installer has the permissions to create it automatically. For more information, please see INSTALL.txt or the on-line handbook.

I tried changing permissions in Ubuntu by left click files folder> permisions> set to read&write, But the box is red and when I save it, it reverts back to the line..... that didnt work! So I also went into php admin and granted admin access to example1.dev. Nope, didnt work either. OK, I read everywhere that I need to change permissions to 777, like everyone in the world knows how to to this! Nope. How please?

Please just help.... Assume I know nothing. Thanks!

Comments

Have you tried drush quickstart-fixperms?

jedihe's picture

Have you tried drush quickstart-fixperms? (by doing drush help qf you can find the help text for it).

Still stuck

Ramanonos's picture

Hi, yes I installed everything using the drush commands per quickstart tutorial. I created the example1.dev folder, then replaced it's contents with open atrium. I then renamed the Default.install.php file to install.php, and created a files folder inside default. Im not sure why I'm having this problem, but it looks like a permission issue with the file folder. I can't figure out how to open up read/write permissions through ubuntu. Any ideas?

I followed the directions below verbatim, and wiped out the appliance and started over a few times as well. I'm at a loss. I think if I knew how to open permissions to Apache I'd be all set. Any ideas?

https://community.openatrium.com/documentation-en/node/2098

Had that issue .. my solution

tlynnec's picture

Hi Ramanonos,

I had that same issue the first time i set up quickstart a few versions back.

In the OA quickstart instructions it says "Make sure the folder example1.dev -> sites -> default is writeable by the group named quickstart."

What I ended up doing was changing the permission on the folders example1.dev AND example1.dev->sites AND example1.dev->sites->default to writeable, then finishing my install. Once OA is installed, I changed the folders example1.dev and example1.dev->sites back to the default permissions (make sure you write down what the default is before you make the folders writeable). You must leave the folder example1.dev->sites->default writeable.

To change the permissions, you'll need the ubuntu/unix password. In quickstart that's "quickstart". Make sure you are changing permissions for the "quickstart" group and not any other. Also, make sure you are logged into ubuntu with admin status.

I hope this helps you. Good luck!
-tlynnec

sudo

semiuniversal's picture

Hi Ramanonos, et al,
I also am very new to Ubuntu and have been having similar issues. I don't want to promote a "blind leading the blind" situation and I am certainly no expert, but based on your questions I think you may not understand that in UNIX-based systems the issue of ownership of files and processes is rather more complex for the end-user than in Windows, for example. You can't change the permissions on a file or folder unless you are logged in as someone who "owns" the file already. Fortunately there is a shortcut command, sudo, that allows you to temporarily impersonate the administrator. If you prefix your command (like chmod, e.g.) with "sudo " it will run as though you are the admin.

It is worth noting that if you go to the command line and enter "drush help quickstart-fixperms" you get the following help text:

Fix permissions for a quickstart development website:
  $ sudo chown -R quickstart:www-data <codepath>
  $ sudo chmod -R a=,u=rwX,g=rX <codepath>
  $ sudo find <codepath>/sites -type d -name files -exec chmod -R a=,ug=rwX '{}' \;
...

So it appears that drush is using sudo, and you can too.

I urge you to use this information as a clue to help you find the right documentation, not as any kind of definitive answer, as I am unqualified provide such. I'm just trying to share the result of my confusion and consequent research.
-williamtremblay

If I can impersonate the root

Ramanonos's picture

If I can impersonate the root via sudo, how do I grant permissions to the default folder?

chown (or chgrp)

semiuniversal's picture

You could change the ownership of the file to your ordinary user account. http://en.wikipedia.org/wiki/Chown will get you started. There may well be a better way, it's just what I have found so far.
-williamtremblay

Thanks. I know my unix PW, but how do I...

Ramanonos's picture

Thanks. I know my unix PW, but how do I change the permissions in UNIX? Specifically, how do I 1. log-in to Ubuntu as the root, then 2. change the default folder permission to write?

I think you haven't run

jedihe's picture

I think you haven't run "drush quickstart-fixperms" (without quotes), since you only report on doing the procedure indicated in the OA documentation.

link?

tlynnec's picture

Sounds like a handy tool, jedihe. For someone who's only ever used drush to follow the install commands in quickstart and basically doesn't understand drush (like me) where do you find the drush qf help file and/or instructions? Please point the way! :)
Thanks

On a terminal, run "drush

jedihe's picture

On a terminal, run "drush help qf" (without the quotes) and use the examples as guidance.

I ran drush quickstart-fixperms

Ramanonos's picture

I ran drush quickstart-fixperms, but it returned the following errors

'--domain' must be at least 3 characters long. [error]
'--domain' must include a . for drupal installer to work. [error]
'--domain' is a required option for this command. [error]
Bad parameters. [error]

need to specify domain

semiuniversal's picture

The reason it barfed on you is that drush did not know which domain you wanted to fix the permissions for. Let's say your domain was "test.dev". In that case you'd run

drush quickstart-fixperms --domain=test.dev

There are very specific requirements on how you can name your sites. It seems that the overall name of the domain must be at least 3 characters no more than 16 characters, it must contain a single dot (which counts as a character).

-williamtremblay

Thanks. I'm liking Drush. A new problem

Ramanonos's picture

Thanks. I'm liking the Drush commands. A new problem has just popped up now. I get to the DB step on install (see below). I entered example_1 as my DB name, root as my UN, and quickstart as my PW... Any thoughts? Should I muck around with the setting.php file? How do I dump clean my example_1 DB?

I then get this message:

Drupal already installed

* To start over, you must empty your existing database.
* To install to a different database, edit the appropriate settings.php file in the sites folder.
* To upgrade an existing installation, proceed to the update script.
* View your existing site.

All set.

Ramanonos's picture

All set. Remember to blow out your existing database. It will recreate a new one for you on install

Tried sudo drush

Argus's picture

Tried sudo drush quickstart-fixperms --domain=example.dev with the default install of example.dev, and I get

Fatal error: Uncaught exception 'Exception' with message ' in /home/quickstart/quickstart/drush/quickstart.inc on line 30

Exception:
  chown: cannot access `/home/root/websites/example.dev': No such file or directory in /home/quickstart/quickstart/drush/quickstart.inc on line 30

using QuickStart 0.9.1

edit: It worked ok when I used the command without sudo :)

Which I find strange because I cannot run "drush dl modulename" whitout sudo, else I get errors.

beget's picture

I had days of similar permissions issues with QuickStart, Drush, and Drupal, especially after using rsync to sync sites between my QuickStart VirtualBox (@dev) server and my 1and1 CentOS/Plesk Cloud VPS production (@prod) server. I couldn't use quickstart-fixperms because I use domains with more than one "." and that are longer than 16 characters so in the end, I had to create the following two scripts for resetting permissions (one for @dev, one for @prod).

Defaults


Obviously, replace these values with your own before running the script.

QuickStart(Ubuntu) User: quickstart
Apache User: www-data
Domain Name: example.com (@prod) example.dev (@dev)
Plesk User: ringo (this is the username associated with the Plesk account. It's also the username of your FTP and SSH accounts)

@dev script

I run this script on my QuickStart (@dev) box after rsync-ing from the @prod to the @dev server AND before I rsync my site from the @dev to the @prod server.

#!/bin/sh

#set defualt owner (quickstart:www-data) on all files and folders to the quickstart user
chown -cR quickstart:www-data /home/quickstart/websites/example.dev/

#set default perms first for all folders (775), then for all all files (664)
find /home/quickstart/websites/example.dev/ -type d -exec chmod 775 {} \;
find /home/quickstart/websites/example.dev/ -type f -exec chmod 664 {} \;

#set perms for default site's folders (775) and files (664)
find /home/quickstart/websites/example.dev/sites/example.com/files -type d -exec chmod 775 {} \;
find /home/quickstart/websites/example.dev/sites/example.com/files -type f -exec chmod 664 {} \;

#set special perms for backup_migrate files (644)
find /home/quickstart/websites/example.dev/sites/example.com/files/backup_migrate -type f -exec chmod 644 {} \;

#set site's files contents owner (www-data:www-data) and folder owner (quickstart:www-data)
chown -cR www-data:www-data /home/quickstart/websites/example.dev/sites/example.com/files/
chown quickstart:www-data /home/quickstart/websites/example.dev/sites/example.com/files/

#set permissions (777) for the site's files folder
chmod -c 777 /home/quickstart/websites/example.dev/sites/example.com/files/

#set the site root's perms (775) and ownership (quickstart:www-data)
chown quickstart:www-data /home/quickstart/websites/example.dev/
chmod 775 /home/quickstart/websites/example.dev/

#set tmp file folder perms (777) and owner (quickstart:www-data)
mkdir /home/quickstart/websites/example.dev/tmp/
chmod -cR 777 /home/quickstart/websites/example.dev/tmp/
chown quickstart:www-data /home/quickstart/websites/example.dev/tmp/

#set owner  (root:root) for plesk-stat folder on plesk systems
chown -cR root:root /home/quickstart/websites/example.dev/plesk-stat/

#End batch file

@dev specifics

If you need to manipulate the files in the site's files folder (sites/example.com/files) from the QuickStart Virtual Box, you need to take ownsership of this folder and its contents. When you're done and BEFORE viewing your site in a browser, you'll need to re-give apache (www-data) ownserhip of these files and folder.

Give quickstart user ownership:

chown -cR www-data:www-data /home/quickstart/websites/example.dev/sites/example.com/files/
chown quickstart:www-data /home/quickstart/websites/example.dev/sites/example.com/files/

Give apache user (www-data) ownership*:

chown -cR www-data:www-data /home/quickstart/websites/example.dev/sites/example.com/files/
chown quickstart:www-data /home/quickstart/websites/example.dev/sites/example.com/files/

*You can also use this code to reset the ownership of the files in the when your local (@dev) Drupal installation reports having trouble accessing the site's files folder. This is not to be run on the @prod server although, you can run a similar script on the @prod server but replacing the user:group with the user:group from the same lines on the @prod script below.

@prod script

  • I run this script on the prod server (usually via ssh) IMMEDIATELY after I rsync my site from @dev to @prod.
  • I put the site in maintenance mode BEFORE running this script and then take the site out AFTER.

#!/bin/sh

#set defualt owner (ringo:psacln) on all files and folders to the quickstart user
chown -cR ringo:psacln /var/www/vhosts/example.com/

#set default perms first for all folders (775), then for all all files (664)
find /var/www/vhosts/example.com -type d -exec chmod 755 {} \;
find /var/www/vhosts/example.com -type f -exec chmod 644 {} \;

#set perms for default site's folders (775) and files (664)
find /var/www/vhosts/example.com/sites/example.com/files -type d -exec chmod 775 {} \;
find /var/www/vhosts/example.com/sites/example.com/files -type f -exec chmod 664 {} \;

#set special perms for backup_migrate files (644)
find /var/www/vhosts/example.com/sites/example.com/files/backup_migrate -type f -exec chmod 644 {} \;

#set site's files contents owner (apache:apache) and folder owner (ringo:psacln)
chown -cR apache:apache /var/www/vhosts/example.com/sites/example.com/files/
chown ringo:psacln /var/www/vhosts/example.com/sites/example.com/files/

#set permissions (777) for the site's files folder
chmod -c 777 /var/www/vhosts/example.com/sites/example.com/files/

#set the site root's perms (775) and ownership (ringo:psaserv)
chown ringo:psaserv /var/www/vhosts/example.com/
chmod 750 /var/www/vhosts/example.com/

#set tmp file folder perms (777) and owner (ringo:psacln)
mkdir /var/www/vhosts/example.com/tmp/
chmod -cR 777 /var/www/vhosts/example.com/tmp/
chown ringo:psacln /var/www/vhosts/example.com/tmp/

#set owner (root:root) for plesk-stat folder on plesk systems
chown -cR root:root /var/www/vhosts/example.com/plesk-stat/

#end batch file

A couple of notes.

  • Obviously, backup first. This works for me using a QuickStart VirtualBox as my @dev server and a 1and1 Cloud Server running CentOS and Plesk 10 as my @prod server. I make no guarantees (obviously).
  • I always prep my sites for possible multi-site installations and use example.com/sites/example.com instead of example.com/sites/default. If you use the latter format, update the paths in the script accordingly.
  • Using multisite also means that i create a symbolic link (ln -s example.com example.dev) in the @dev server's sites folder so that things work when previewing the site locally.

Update 1: 8 May 2011 09:08 GMT -6
The same script with very little modification (including having to use sudo) works on production sites on RackSpace's Cloud (uBuntu and CentOS) and 1and1's VPS Cloud (CentOS).

Update 2: 26 May 2011 12:26 GMT -6
The www-data user and group may or may not be the user your website runs as under Apache. For example, when using SuEXEC or SuPHP, your website's likely running as a real user. By default though, www-data is the user under mod-PHP, Fast-CGI, or CGI so long as SuEXEC or SuPHP isn't enabled and overriding that.

Quickstart Drupal Development Environment

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week