Support

We do NOT control the ownership of your files. We can't, at all. Our PHP software runs, well, inside PHP itself. PHP is constrained to run under a specific user based on what the server administrator (that's you) has configured in the server (that's your server / container).

The obvious reply to your issue is to figure out your container setup so everything is a using the same user. This is way beyond the scope of our support.

 I will not try to debate whose responsibility it is to set the proper ownership of a file that is created by UNiTE. 

I WILL debate this and I do not appreciate your sarcasm. Being sarcastic against the person trying to help you only works against you. It won't change the fact that this is how YOUR server works, according to how YOU set it up.

Once again. There is NO PHP function that can change the ownership of a file. PHP can only change the permissions of a file. The ownership of the file is the same user and group the PHP process runs under. This is how PHP works. If you don't understand that try to educate yourself by listening to people who know these things better than you and / or reading up on the subject. A good place to start is the Security Information chapter of the Akeeba Backup documentation which I wrote to educate people like you.

After running UNiTE, the ownership of the .htaccess file is now correctly set to 'www-data'. However, its contents is rather peculiar:

When UNiTE starts extracting your site it writes a "stealth .htaccess" like Kickstart's eponymous option. This makes your site inaccessible to other people while the restoration is in progress. The .htaccess file is extracted as htaccess.bak. When UNiTE finishes the restoration successfully it will remove its .htaccess file and rename htaccess.bak to .htaccess just like Kickstart does.

So, one of the following is going on:

• UNiTE did not finish restoring the site. It tells you whether it's successful or not. Check its output.
• You had a htaccess.bak file in your backup with these contents, backed up AFTER .htaccess itself. First the .htaccess is extracted as htaccess.bak. Then the "wrong" htaccess.bak is extracted, overwriting the previous file. At the end of the restoration the "wrong" file is renamed to .htaccess.
• These were the contents of the .htaccess file of your site. This could happen if you had started a restoration with Kickstart but never ran the Clean Up step.

For your information, I am using Akeeba UNiTE on a daily basis. I restore the latest backup of our site on my dev machine. I also use it 2-3 times every week to transfer dev sites between two different dev machines. Needless to say, there are .htaccess files in all of these cases. I know how to set up my own servers and have done that in a way that doesn't cause any of the problems you have. You know how? I have set up a specific user which owns all of the files, it's the same one Apache and PHP-FPM are using and the same one that runs Akeeba UNiTE.

Whenever I use Docker I use a variation of https://github.com/nikosdion/efficacious-whale which has the files hosted outside the container. However, Docker is too slow for practical development so I'd rather use a virtual machine or my dev machine directly.

So, yes, I am pretty damn sure that your problem is self-inflicted and comes down to server configuration. I understand exactly how file ownership / permissions work and the same for Linux, macOS, Windows, Apache, PHP and Docker. What do you think? I write a backup application for 15 years that just happens to work across a plethora of server environments? There's a lot of hard work and VERY specific domain knowledge about servers that goes into making and maintaining it. So, maybe, you'd like to just fix your setup instead of being a sarcastic jerk? Thanks.

You came here with a file ownership issue. I explained very calmly that our PHP-based software runs inside PHP itself which determines the file ownership. Remember that this is the ONLY thing you had asked me at this point.

Your reply was and I quote:

I will not try to debate whose responsibility it is to set the proper ownership of a file that is created by UNiTE. 

Do you understand how that reads? It tells me that you don't know or care about how your server, the Docker container that you set up yourself, works. You are going to irrationally blame me for your wrong configuration. I explained once again how PHP works, something that is objectively outside the scope of our support.

It would be merely offensive if it stopped there. You then continue to change your question into something different, telling me about the content of the .htaccess content pretending that I said that this was outside the scope of our support. No, I didn't. I had only replied to the ownership because it wasn't right and it was caused by a server issue. Without this resolved I couldn't tell you anything more. I was also not told before what are its contents, which is very important for understanding your issue. Despite that, I did explain how UNiTE works and the conditions under which your issue could occur.

Before calling me a bully, after I have already helped you with your issue, please take a moment to assess your behaviour to me. I replied in a FAR LESS offensive tone than yours and only AFTER answering your question. If that makes me a bully, what does your behaviour and your doubling down on calling me names and making wrongful allegations make you?

As for your allegations about my behaviour, please let me say this. I know what I know and I know what I don't know. I do NOT expect people to know everything I do and I DO NOT talk people down just because they don't share my very particular domain-specific knowledge. When people are willing to learn more I go out of my way to help them, despite being outside the scope of our support. When people are behaving like entitled jerks, belittling me, being sarcastic, having irrational demands, retroactively misinterpreting my replies based on information they didn't share in advance or call me names I will respond in kind — after trying to address their technical issue.

In short, your experience of an interaction with me depends solely on how you treat me. It's called reciprocity.

If you are truly interested in resolving your issue, I am here to hold a further technical discussion. Let me remind you the relevant technical help points I made in my previous replies:

• File ownership (user and group that owns the file) is controlled by the operating system. It will be the same user and group PHP runs under. Your use of su proved that point beyond any doubt.
• File permissions are also controlled by the operating system. Check the default user mask for your user. How to do that depends on your Linux distribution.
• When UNiTE starts extracting your site it writes a "stealth .htaccess" like Kickstart's eponymous option. This makes your site inaccessible to other people while the restoration is in progress. The .htaccess file is extracted as htaccess.bak. When UNiTE finishes the restoration successfully it will remove its .htaccess file and rename htaccess.bak to .htaccess just like Kickstart does.
•  Based on the information you have provided so far one of the following happens:
  • UNiTE did not finish restoring the site. It tells you whether it's successful or not. Check its output.
  • You had a htaccess.bak file in your backup with these contents, backed up AFTER .htaccess itself. First the .htaccess is extracted as htaccess.bak. Then the "wrong" htaccess.bak is extracted, overwriting the previous file. At the end of the restoration the "wrong" file is renamed to .htaccess. You may want to check the backup log.
  • These were the contents of the .htaccess file of your site. This could happen if you had started a restoration with Kickstart but never ran the Clean Up step. Check the backup log.

If I were to make an educated guess, I would say that your UNiTE run did not finish successfully. This would explain why the stealth .htaccess file is left behind. So, let's take it from there and please treat me the way you'd like to be treated.