Problems, need help? Have a tip or advice? Post it here.
7 posts Page 1 of 1
Hello all,

I have been googling this problem for the past few days, and have read numerous posts on this forum which are related, so I think now what I am asking for is not "how do I fix this?" but "is it safe to fix this, and if so, why?"

In essence, I am having a problem that others seem to have run into quite often - I have launched the editable pages which work fine, apart from the editable region type='file'. When pressing the 'Browse Server' button a pop-up appears stating "Cannot write to upload folder. /htdocs/couch/uploads"

The Couch directory is set to 775 (recursive permissions). My previous experience with Couch, and an initial check of these forums, suggested that setting permissions to 777 might fix this. I created a test directory "/htdocs/uploads" and amended couch's config file to point the upload_dir to that test directory. I set the test directory to 775 permissions, and received the same error message. I then set the test directory to 777 permissions, and the file uploader works.

I therefore asked my colleagues in IT to set the Couch folder to 777 (recursive) permissions. Whilst they are willing to do that on this test server, which I am using as 'proof of concept' for this project, they have said that they would not be willing to do so on the production server when the project goes live.

What my colleagues in IT have said is that "777 means that anybody can write to it ... that means a pretty insecure website" and that this "is outside our area of expertise so it might be worth asking the couch forum how they recommend setting up security or accounts/access for couch on the htdocs directory".

This is outside my area of knowledge/experience too (but I'm always willing to learn!!) I suppose my initial 'pondering' is this: if a directory has a 'group' and an 'owner', what does couch 'appear as' in that regard? Can couch be the owner? belong to the group? be a permitted user with specific rwx permissions? What credentials are being passed to / seen by the server when couch handles an edit? Is that even a relevant question?

And, given how commonly recommended it is on this forum and on others (such as support for kcfinder), is 777 insecure?

Thank you for any help you can provide!

(n.b. this project is an internal website for my colleagues which will display guidance on internal processes, along with providing relevant documents to go with the guidance. The 'website' will be deployed on an internal server with a LAMP stack, and will be available only over intranet.)


I have continued doing research, and trying to solve this myself - I am hoping that someone with server management experience is able to help me, since my colleagues in IT have stated that they do not have knowledge or experience of PHP, webhosting or CMS.

What they have deployed for me is a Bitnami LAMP stack. I found some Bitnami documentation for Wordpress which said that the owner/group would be bitnami:daemon. I checked what the cms php user output was by adding
Code: Select all
to my index.php file, and it confirmed a username of 'daemon'. The owner and group for all directories, including couch, is bitnami:bitnami. I proposed that we should change the 'couch' folder on the server to bitnami:daemon.

Colleagues in IT have said that this server
"is a bare ‘out of the box’ bitnami configuration and just a few tweaks such as loading up couch as per the site instructions. Nothing in the couch instructions referred to any default folder permissions or changes required.
I can only suggest you go back to the couch developer and clarify if the owner bitnami can be used for couch administration as there is clearly some conflict with accounts and permissions under couch install.
Otherwise they will be the best source of advice with regards to ensuring the permissions are set correctly"

Would someone please be kind enough to explain the basics of what is going on here, and what the correct setup is for our server?

Thank you.

Hi Anthony,

I'll try put my two cents in here.
Please pardon my delving into a bit of introductory theory first.

As you, of course, know each of the three digits in a permission (e.g. '775' that you mentioned) target a distinct entity.
The first digit is meant for the 'owner', the second for the 'group' and the last for 'everybody'.
The 'value' of the digit (e.g. 7 or 5) itself denotes the level of permission that is granted to the entity being targeted.

So in our example, the 'owner' has '7' (which is full permission), the 'group' also has the same '7' while 'everybody' has '5' (which would denote that everybody does not have 'write' permission).

It becomes clear that with a permission of '777', the last digit is the one causing consternation because it would give full permission to everybody. In deference, let us take the assertion that '755' (which now limits the write permission to only the owner) is the most practical permission at face value and assume it is the truth.

Assuming your 'upload' folder is set with '755', it is clear that no one except the owner of that folder would be able to save anything into it. So who is that owner?

That depends on how the server administrator has set things up. Mostly it is your user account (the 'username' part in '/home/username/public_html' of your site) but it could be any account. For our discussion let us suppose it is 'xyz'.

So only 'xyz' account can write anything into upload folder.
If Couch is expected to write anything into that folder, it absolutely has to be executed by that 'xyz' account.

Actually it is not Couch that is trying to do the write stuff - it is PHP and, by extension, the HTTP Daemon i.e. your web server. Your web server has to run under the 'xyz' account if Couch is to succeed in putting a file into the upload folder.

Since Couch is not able to that, it is safe to assume that the account owning the folder and the account running the web server are different.

What can we do about it?
If you absolutely must have 755 permission, then make the account running the web server the owner of your site as well (this is common in shared hosting scenarios - incidentally this is the reason why you mostly don't run into this problem on such hosts).

If this single ownership is not possible, then you may place the user account owning the folder in the same 'group' as the account running the web server (remember the second digit in permission pertains to 'group'). With this arrangement, you can then use a permission on '775' which, like '755', avoids giving the dreaded '7' to 'everybody' and hence should be just as safe.

For learning how to find the accounts/groups owning the site and running the web server and making the required changes, I recommend you please see the following article that explains it brilliantly (it talks about Wordpress but everything applies to any other PHP application as well)- ... wnerships/

In closing, I must say that Couch (or any PHP script for that matter) has no say in either the occurrence or the rectification of this problem - it is squarely a server configuration issue.

Hope the answer helps.
KK, thank you for such an extremely helpful reply. This is exactly what I needed to understand so that I could explain to my colleagues in IT what I need, and assure them that this is the proper way to do it. I will be doing a bit more reading up on Web Server configuration, and in particular these LAMP stacks, because I think they are likely to come up again for me and it would be great to know more about them.

Thanks again!

You are welcome :)

Sorry to revive what I thought was a closed issue, but it would seem that there are still gaps in my understanding.

The IT department have now deployed the 'live' server, and I am now trying to launch the website which had been working perfectly well in the test server. I am, once again, struggling and failing to get the permissions set so that Couch is able to upload files.

The server is:
Ubuntu 18:04 LTS with:
Apache 2.4.29
MySQL: 5.7.28
PHP 7.2.24
myPHPAdmin: 4.9.4 with Curl and mbstring, upgraded for compatibility with PHP 7.2
Couch: 2.2.1

the default web directory is /var/www/html - therefore the couch uploads folder is /var/www/html/couch/uploads

Apache is running as user:group "www-data:www-data"

From my understanding of what you previously posted, and my reading of the linked article, we should be able to make the uploads folder belong to group www-data and give r/w permissions to the group and this would then allow couch access to the uploads folder? we did:

sudo chown -R root:www-data /var/www/html/couch/uploads
sudo chmod -R 765 /var/www/html/couch/uploads

This has not achieved the outcome I was hoping for, and I still get the error "Cannot write to upload folder. /var/www/html/couch/uploads"

If it helps shed any light, using the below line of code on index.php:

Code: Select all

returns the following:

Code: Select all
Array ( [name] => www-data [passwd] => x [uid] => 33 [gid] => 33 [gecos] => www-data [dir] => /var/www [shell] => /usr/sbin/nologin )

As mentioned previously IT Dept. are very security conscious, but also do not have expertise in managing servers like this.
Any help you could give would be gratefully received.
From what you posted, it seems the permission granted to the group is "6" (middle digit of "765").
Translated, it would mean Allow Read, Allow Write, Disallow Execute.

Now, strange as it might seem, 'write' permission without 'execute' is practically useless in Linux (because 'execute' is required for making changes to the file system when something is written into it).

Please ask your team to use "775" instead.

Hope this helps. Do let me know.
@KK thank you very much for that!

In my research I had come across bits of advice that suggested that for security reasons it would be a bad idea to give Apache both write and execute permissions, since this might enable malicious php to be written to a folder and executed from it. I didn't fully understand how this works when I read the advice, but it sounded sensible to keep the two permissions separate. I am assuming, then, that this is not a security concern and that it is common practice to give write and execute permissions to Apache?

I will go back to the IT team and ask for 775 permissions to be set.

Thanks again

7 posts Page 1 of 1

Who is online

In total there are 14 users online :: 1 registered, 0 hidden and 13 guests
(based on users active over the past 5 minutes)

Users browsing this forum: Google [Bot] and 13 guests