Mastering Linux File Ownership: The `chown` Command for Hosting Environments

Operating a website, whether it’s a dynamic e-commerce platform, a content-rich blog, or a complex web application, hinges on more than just powerful hardware and robust network infrastructure. At the core of every stable, secure, and performant Linux-based hosting environment lies a fundamental concept: file ownership. For those actively seeking a reliable hosting solution, understanding how to manage file ownership using the chown command is not merely a technical detail; it’s a critical skill that directly impacts your site’s security, functionality, and overall resilience.

You’re likely researching hosting because you need control, performance, and peace of mind. Without proper file ownership, your web server might fail to read essential configuration files, your scripts could encounter permission errors, or worse, your site could become vulnerable to unauthorized access. This isn’t about rote memorization of commands; it’s about safeguarding your digital assets and ensuring your online presence operates flawlessly. Let’s delve into how chown provides that essential layer of control and why it’s indispensable for anyone managing a Linux server, from a private VPS to a full dedicated server.

Understanding `chown`: The Foundation of Linux File Ownership

The chown command, short for “change owner,” is a powerful utility in Linux and Unix-like operating systems that allows you to alter the user and/or group ownership of files and directories. Every file and directory on a Linux system is associated with an owner (a user) and a group. These assignments are not arbitrary; they dictate who can read, write, or execute a file based on the permissions set for the owner, the group, and others.

The Syntax and Core Functionality of `chown`

The basic syntax for chown is straightforward, yet its impact is profound:

chown [OPTIONS] USER[:GROUP] FILE(S)

USER: This specifies the new owner of the file or directory. This can be a username (e.g., www-data, myuser) or a numeric User ID (UID).
GROUP: Optionally, you can also specify a new group for the file or directory. This is separated from the user by a colon (:). If you only want to change the group, you can omit the user and just use :GROUP (though chgrp is often preferred for group-only changes).
FILE(S): This is the path to the file(s) or directory(ies) whose ownership you want to change. You can specify multiple files, or use wildcards.

Common `chown` Options and Their Significance

To wield chown effectively in a hosting context, understanding its common options is crucial:

-R, --recursive: This is perhaps the most frequently used option in web hosting scenarios. It tells chown to recursively change the ownership of directories and their contents. Without -R, chown would only affect the specified directory itself, leaving all its subdirectories and files untouched. For web roots or application folders, this is indispensable.
-v, --verbose: Provides a detailed output of every file or directory whose ownership is changed. This is excellent for verification, especially when dealing with large numbers of files or performing recursive operations.
-c, --changes: Similar to -v, but only reports when a change is actually made. Useful for seeing only the “effective” changes.
--from=CURRENT_OWNER:CURRENT_GROUP: This powerful option allows you to change ownership only if the current owner and/or group match the specified values. This can be a safeguard against unintended changes.

Why File Ownership is Paramount for Web Hosting Stability and Security

In a production hosting environment, incorrect file ownership can lead to a cascade of problems, ranging from minor annoyances to critical security breaches. It’s a fundamental aspect of system hardening that directly impacts your site’s ability to serve content, process data, and defend against threats.

Ensuring Web Server Functionality

Your web server software (Apache, Nginx, LiteSpeed, etc.) needs specific permissions to read and serve your website’s files. Typically, these web servers run under a dedicated, non-privileged user and group (e.g., www-data on Debian/Ubuntu, nginx on RHEL/CentOS, or a specific user created by a control panel like cPanel). If your website files are owned by root or another user the web server doesn’t have access to, visitors will encounter “403 Forbidden” errors or broken pages because the server simply cannot read the content.

Moreover, dynamic applications like WordPress or custom PHP scripts often need to write to specific directories (e.g., for uploads, cache, logs). If these directories are not owned by, or at least writable by, the web server’s user/group, these operations will fail, leading to application errors and a poor user experience. Correct ownership ensures your application has the necessary read and write capabilities without granting excessive privileges.

Bolstering Security Posture

Security is not an afterthought in hosting; it’s an ongoing commitment. File ownership plays a vital role in the principle of least privilege. By assigning the minimum necessary ownership, you limit the damage an attacker can inflict if they manage to compromise a part of your system.

Preventing Unauthorized Writes: If your web application files (e.g., PHP scripts) are owned by the web server user, and that user account is compromised, an attacker could modify those files. By having sensitive files owned by a separate, less privileged user (e.g., your SFTP user) and only granting the web server read access, you make it harder for an attacker to persist changes.
Containing Breaches: In a multi-site or multi-user environment, ensuring each website’s files are owned by its specific user and group helps isolate potential compromises. A breach in one site cannot easily spread to another if file ownership prevents cross-site access. This is especially relevant on shared hosting or even VPS instances running multiple domains.
Mitigating Exploit Chains: Many web application exploits rely on gaining control over the web server’s process. If that process then tries to modify files it doesn’t own or have write permissions to, the exploit chain can be broken, significantly reducing the attacker’s capabilities.

Facilitating Team Collaboration and Management

When multiple individuals or teams are working on a website (developers, designers, content managers), proper file ownership simplifies access management. By creating specific user accounts and assigning appropriate ownership and group memberships, you can grant granular control over different parts of your project without sharing root credentials or broadly opening permissions. For instance, a developer might own the application code, while an image editor might be part of a group that can write to the uploads directory.

Real-World Implementation Example: Migrating a WordPress Site to a New Server

Imagine your business is growing, and your current shared hosting solution can no longer keep up with traffic demands. You’ve decided to migrate your WordPress site to a more powerful netherlands vps for better performance and control. After transferring all your files via SFTP or rsync, you’re faced with the critical task of setting up correct file ownership and permissions.

The Scenario: Post-Migration WordPress File Setup

Let’s say your old server used a custom user account, old_wp_user, to own your WordPress files. On your new Netherlands VPS running Ubuntu with Apache, the web server typically runs as the www-data user and group. If you simply copy the files, they will likely retain their original ownership (old_wp_user), or perhaps be owned by the user who performed the transfer (e.g., root if you used sudo rsync without careful attention). If left as is, your WordPress site will almost certainly display errors or fail to load.

Step-by-Step `chown` Application

Here’s how you would use chown to correct this, assuming your WordPress installation is located at /var/www/html/yourdomain.com:

Identify the Web Server User/Group:
On most Debian/Ubuntu systems using Apache, this is www-data:www-data. For Nginx on CentOS/RHEL, it might be nginx:nginx. Confirm this by checking your web server’s configuration or running ps aux | grep apache or ps aux | grep nginx and looking at the user column for the main processes.
Change Ownership of Your WordPress Root Directory:
The primary directory for your WordPress installation needs to be owned by the web server user and group so the server can read and write to it. Execute the command with recursive option:

sudo chown -R www-data:www-data /var/www/html/yourdomain.com

This command changes the owner to www-data and the group to www-data for the yourdomain.com directory and all its subdirectories and files.
Refine Permissions (Important Complement to Ownership):
While chown handles ownership, you’ll also need to set correct file permissions using chmod. A common secure setup for WordPress is:
- Directories: 755 (owner can read, write, execute; group and others can read, execute)
- Files: 644 (owner can read, write; group and others can read)
You can achieve this with:

sudo find /var/www/html/yourdomain.com -type d -exec chmod 755 {} \;

sudo find /var/www/html/yourdomain.com -type f -exec chmod 644 {} \;

Note: For wp-config.php, a permission of 640 or even 600 is often recommended for enhanced security, owned by the web server user.
Handle Uploads and Cache Directories (if applicable):
Some directories like wp-content/uploads or cache directories might need slightly more permissive group write access (e.g., 775 for directories) if specific plugins or themes need to write to them without being the direct owner. However, always exercise caution and use the principle of least privilege.

After these steps, your WordPress site on the new Netherlands VPS should load correctly, allowing the web server to access all necessary files and your application to perform its functions, from saving media uploads to updating themes and plugins. This precise application of chown (and chmod) ensures both functionality and a strong security foundation.

Comparison: `chown` vs. `chmod` vs. `chgrp` – Distinct Roles in File Management

While often used in conjunction, `chown`, `chmod`, and `chgrp` serve fundamentally different purposes. Understanding their individual roles is crucial for effective and secure system administration, especially when managing hosting resources like a Dedicated Server or a robust premium hosting package.

`chown`: Changing Ownership

Performance: Generally low impact for single files. Recursive operations on millions of files can be I/O intensive but are typically a one-off setup task, not a continuous operational burden.
Security: Crucial for implementing the principle of least privilege, isolating users/applications, and preventing unauthorized modification or access.
Cost: No direct cost, but incorrect use can lead to downtime or security breaches, incurring significant indirect costs.
Scalability: Operates effectively across any number of files/directories. Scripts can automate `chown` across large file systems during deployments or migrations.
Ease of Management: Relatively easy to learn and apply. Requires knowing target user/group names.
Recommended Use Cases:
- Assigning website files to the web server user (e.g., www-data, nginx).
- Granting specific user accounts ownership of their home directories or project folders.
- Correcting file ownership after migrations or backups.
- Isolating application files to prevent cross-account access.

`chmod`: Changing Permissions

Performance: Similar to `chown`, low impact for single files, potentially I/O intensive for recursive operations on large datasets.
Security: Absolutely critical for controlling read, write, and execute access for the owner, group, and others. Misconfigured permissions (e.g., `777`) are a leading cause of security vulnerabilities.
Cost: No direct cost. Incorrect permissions are a major source of security exploits and application failures, leading to significant incident response costs.
Scalability: Scales well; can be applied recursively and automated.
Ease of Management: Requires understanding octal or symbolic notation and the implications of each bit (read, write, execute). Can be more complex to master than `chown`.
Recommended Use Cases:
- Setting secure access rights for web application files (e.g., 644 for files, 755 for directories).
- Restricting access to sensitive configuration files (e.g., 600 for database credentials).
- Enabling script execution (755 for executables).
- Protecting log files from unauthorized viewing.

`chgrp`: Changing Group Ownership

Performance: Identical to `chown` for group changes – low impact generally.
Security: Essential for managing shared access within teams or between specific applications. Allows multiple users in a group to have specific permissions on files without being the direct owner.
Cost: No direct cost. Essential for maintaining secure collaborative environments.
Scalability: Scales well, can be used recursively and automated.
Ease of Management: Simple to use, similar to `chown` but focused only on the group.
Recommended Use Cases:
- Allowing a development team (e.g., all members of the devs group) to read/write to a shared project directory.
- Ensuring the web server group has read access to static assets.
- Setting up a common group for shared resources among different services.

In essence, `chown` answers “who owns this?”, `chmod` answers “what can they do with it?”, and `chgrp` answers “who else can collaborate with similar privileges?”. All three are indispensable tools in the toolkit of anyone managing a Linux server environment.

Common Deployment Mistakes

Even seasoned administrators can sometimes overlook subtle details when managing file ownership, leading to operational hiccups or security vulnerabilities. Avoiding these common pitfalls ensures a more resilient hosting setup.

Assigning `root` Ownership to Web Server Files:
Mistake: Setting root:root ownership for your entire web root (e.g., /var/www/html). While root can read and write anything, the web server process (e.g., www-data) usually runs as a non-privileged user. If web files are owned by root, the web server user might not have adequate permissions to read, let alone write, to necessary directories like upload folders or cache directories, even if chmod is set to `777`. This also creates a massive security risk, as any compromise of the web server could allow an attacker to write as root.

How to Avoid: Always ensure web server-served files are owned by the user and group that the web server process runs as (e.g., www-data:www-data or nginx:nginx). For files that need tighter control (e.g., configuration files), make them owned by a privileged user but only readable by the web server user, and set appropriate chmod permissions like `600` or `640`.
Forgetting the Recursive Flag (`-R`):
Mistake: Applying chown user:group /path/to/directory without -R. This only changes the ownership of the directory itself, leaving all its contents (subdirectories and files) with their original ownership. Your web application will still fail because the files within the directory haven’t inherited the correct ownership.

How to Avoid: When dealing with entire application installations or large datasets, almost always use the -R flag with chown for directories that contain child elements needing the same ownership.
Confusing Ownership with Permissions:
Mistake: Believing that changing ownership alone solves all access issues, or trying to compensate for incorrect ownership by using overly permissive chmod settings (e.g., `777` on files). This is a common confusion.

How to Avoid: Understand that `chown` (who owns it) and `chmod` (what access they have) are distinct but complementary. First, establish the correct owner and group with chown. Then, apply granular permissions with chmod to define read, write, and execute access for the owner, group, and others. Never use `777` in a production environment; it’s a critical security vulnerability.
Changing Ownership of System Files Recklessly:
Mistake: Indiscriminately applying chown to system-critical directories outside your web root or user home directory without a clear understanding of the implications. Changing ownership of files in /etc, /bin, /usr, etc., can render your system unusable or create massive security holes.

How to Avoid: Always restrict your chown operations to user-managed content, application directories, and your web root. If you must modify system file ownership, understand the default ownership and permissions, back up critical files, and proceed with extreme caution.
Not Verifying After Changes:
Mistake: Executing chown and assuming it worked correctly without checking. Especially with complex commands or wildcards, it’s easy to make a typo that leads to unexpected results.

How to Avoid: Always use ls -l on the affected files and directories after running chown to verify that the owner and group have been changed as intended. Use the -v or -c flags during the `chown` operation for immediate feedback.

When This Hosting Solution Is Not the Right Choice

While `chown` is a fundamental tool for Linux system administration, there are specific scenarios or problem types where focusing solely on ownership changes might be misguided or even detrimental. Recognizing these situations is key to efficient troubleshooting and secure system management.

1. On Highly Restricted Shared Hosting Environments

If you’re on a basic shared hosting plan, your ability to execute chown on files outside your designated user space (e.g., your public_html directory) is typically limited. In many cases, control panels like cPanel handle file ownership abstractly, or the underlying system restricts user-level chown commands on critical system files. Trying to force ownership changes in such environments might lead to errors or, worse, violate your hosting provider’s terms of service. For these basic setups, problems are more often related to `chmod` (permissions) or specific application configurations.

For those requiring greater flexibility and control, a move to a VPS or even cheap offshore hosting with root access offers the full power of `chown` and other system commands.

2. When the Problem is Primarily File Permissions (`chmod`)

A common mistake is to misattribute a permission issue to an ownership issue. If your web server user owns the files but still can’t read or write them, the problem is likely with the `chmod` settings. For example, if a file is owned by www-data:www-data but has permissions set to `000` (no access for anyone), changing ownership again won’t help. Similarly, if a file is owned by the correct user but only the *group* has write access, and your web server isn’t part of that group, you’ll still have issues.

Always verify permissions (`ls -l`) alongside ownership before attempting a `chown` operation. You might find that a simple `chmod` command is all that’s needed.

3. For Transient or Ephemeral File Systems

In highly dynamic cloud environments where containers (like Docker) or serverless functions are used, file systems are often ephemeral or managed by orchestration tools. Directly using `chown` might be counterproductive or quickly overwritten. In these scenarios, file ownership is typically defined within the container image or through orchestration manifests, and changes should be managed at that higher declarative layer rather than with direct `chown` commands on the running instance.

4. As a Substitute for Proper User and Group Management

If you find yourself constantly battling with `chown` to grant access to different team members, it might indicate a more fundamental issue with your user and group management strategy. Instead of repeatedly changing file ownership for individual access, consider:

Creating dedicated Linux user accounts for each team member.
Establishing specific groups for different roles (e.g., devs, qa, content_editors).
Assigning appropriate group ownership with `chgrp` and then using `chmod` to grant group permissions, rather than constantly reassigning direct ownership.

This approach scales better and is more secure.

5. When Dealing with Critical System Files

As mentioned in common mistakes, using `chown` on files outside your immediate control (e.g., files in /bin, /sbin, /etc, core operating system libraries) without a deep understanding of their function and default ownership can severely destabilize your system. These files are typically owned by root for a reason: to prevent unauthorized modification by less privileged users or compromised processes. Altering their ownership can create security vulnerabilities or make your server unbootable.

In these cases, if you suspect an issue with system file ownership, the solution often involves restoring from a backup, re-installing affected packages, or consulting expert support, rather than attempting ad-hoc `chown` commands.

Practical Recommendations

Managing file ownership isn’t just about knowing the `chown` command; it’s about adopting a strategic approach that balances security, functionality, and operational efficiency. These recommendations are vital for anyone serious about maintaining a robust hosting environment, from a simple blog to complex enterprise applications.

Embrace the Principle of Least Privilege (PoLP):
This is the golden rule of security. Grant only the minimum necessary ownership and permissions for a user or application to perform its function. Your web server user (e.g., www-data) should typically own web root directories and files it needs to write to (like upload folders, cache directories) or have read-only access to most others. It should *not* own configuration files containing sensitive database credentials if those files don’t need to be modified by the web server process. Separate ownership for different components whenever feasible.
Document Your Ownership and Permission Schemes:
Especially for complex applications or multi-user environments, clearly document your standard file ownership and permission schemes. This becomes invaluable for new team members, during troubleshooting, or when migrating your application to a new hosting provider or a Dedicated Server.
Automate Ownership Adjustments in Deployment Pipelines:
Manually running `chown` commands after every deployment or migration is prone to human error. Integrate `chown` and `chmod` commands into your deployment scripts (e.g., using Ansible, Chef, or simple shell scripts). This ensures consistency and reproducibility across environments, from development to staging and production.
Regularly Audit File Ownership and Permissions:
Over time, configurations can drift. New plugins, themes, or custom scripts might introduce files with incorrect ownership. Periodically audit your critical directories (especially your web root) for deviations from your established ownership and permission policies. Tools like find can help locate files with specific owners or permissions.
Leverage Groups for Collaborative Access:
When multiple users need shared access to directories or files, use Linux groups effectively. Instead of changing direct ownership, create a group (e.g., devteam), add relevant users to it, change the group ownership of the shared resources using `chgrp`, and then apply appropriate group permissions (`chmod g+w`). This maintains clear individual ownership while enabling collaborative write access.
Backup Before Major Changes:
Before making significant `chown -R` operations on large or critical directories, always perform a backup. This provides a safety net if an unintended ownership change destabilizes your application or system. This is a standard practice for all critical system modifications.

Security Considerations: `chown` as a Defensive Measure

The `chown` command, when used thoughtfully, is a potent tool in your security arsenal. Its primary role is to enforce access control, making it harder for unauthorized entities to tamper with your system or data. Here’s how it contributes to a more secure hosting environment:

Isolation of Application Components: In a modern web application, different components might run with different privileges. For instance, a PHP-FPM process could run as user `php-fpm-user`, while the Nginx server runs as `nginx`. By ensuring PHP files are owned by `php-fpm-user` and Nginx only has read access, you isolate potential vulnerabilities. If the Nginx process is compromised, it won’t have write access to the PHP source code, limiting the attacker’s ability to inject malicious scripts.
Preventing Arbitrary Code Execution and Privilege Escalation: If an attacker manages to upload a malicious script to your server, its ability to execute or modify other files depends heavily on the ownership and permissions. If all sensitive system files are owned by `root` and only readable by others, the malicious script running under a less privileged web server user cannot easily modify system binaries or configuration files, thereby preventing privilege escalation.
Securing Sensitive Configuration Files: Files like wp-config.php (for WordPress), database connection strings, or API keys are highly sensitive. These should typically be owned by a user other than the web server user (e.g., your administrative user) and have very restrictive permissions (e.g., `600` or `640`), ensuring only the specific application process can read them, and no other user can even view them.
Enhancing Multi-Tenancy Security: On servers hosting multiple websites (even a single VPS with several domains), distinct user accounts for each site, coupled with appropriate `chown` and `chmod` settings, are paramount. This ensures that a vulnerability in `siteA.com` cannot be leveraged to read or modify files belonging to `siteB.com`. This isolation is a cornerstone of robust security for providers offering Premium Hosting or even specific forms of Offshore Hosting where privacy and isolation are key.

Performance and Migration Considerations

While `chown` is primarily a security and management tool, its application can have tangential effects on performance and is a critical step in any server migration.

Performance Nuances of `chown`

For most typical operations, `chown` itself is not a performance bottleneck. Changing ownership of a single file is instantaneous. However, there are considerations:

Recursive Operations on Large Datasets: Running `chown -R` on a directory containing millions of files and subdirectories can be I/O intensive. This can temporarily spike disk I/O, especially on slower storage (like traditional HDDs, though less of an issue with modern SSD offshore hosting). While it rarely causes a complete outage, it could lead to momentary latency spikes on a busy server. It’s best performed during off-peak hours or in a controlled maintenance window.
Incorrect Ownership Leading to Functional Performance Issues: If files are owned incorrectly such that the web server or application process cannot access them, this leads to application errors, repeated attempts to access, or fallback mechanisms, all of which consume CPU and I/O cycles, degrading overall application performance. The “performance impact” here isn’t from the `chown` command itself, but from the functional failure that correct ownership prevents.

`chown` as a Critical Step in Server Migration

Migrating a website or application from one hosting environment to another (e.g., from a shared server to a Dedicated Server or a new VPS) almost invariably requires careful attention to file ownership. Different operating systems, control panels, or even different versions of the same web server can use different default user/group accounts.

User and Group Mismatch: Your old server might have used `apache:apache`, while your new one uses `www-data:www-data`. Simply copying files will retain the old ownership, rendering your site inaccessible. Manual or scripted `chown` adjustments are essential post-transfer.
Control Panel Specifics: If migrating from a cPanel server, file ownership might be tied to specific cPanel user accounts. On a new server without cPanel, or with a different control panel, these user IDs will not match, necessitating `chown` to assign files to the new system’s user accounts.
Permissions Recalibration: Often, `chown` is followed immediately by `chmod` adjustments during migrations. The goal is to replicate the secure and functional access model of the old server onto the new one, adapting to the new environment’s user/group structure. Semayra, for example, often assists with ensuring these transitions are smooth, handling the intricate ownership and permission adjustments required for a seamless migration.

FAQ: `chown` and File Ownership in Hosting

Q1: Can I use `chown` on a shared hosting account?

A1: Typically, no, not directly in the same way you would on a VPS or Dedicated Server. On most shared hosting platforms, your access is restricted to your user’s home directory (e.g., public_html), and you usually cannot change the ownership of files to system users like `www-data`. File ownership is often managed by the hosting provider’s control panel or configured automatically. If you encounter ownership issues, it’s usually a permission (`chmod`) problem, or you’d need to contact your host for assistance.

Q2: What is the most common owner:group for web files on a Linux server?

A2: This depends on the Linux distribution and web server software. For Apache on Debian/Ubuntu, it’s very common to see `www-data:www-data`. For Nginx or Apache on CentOS/RHEL, it might be `nginx:nginx` or `apache:apache`. Some control panels create specific user:group combinations for each website (e.g., `user:user` or `user:webapps`). Always verify your specific setup by checking your web server’s configuration or listing processes (`ps aux | grep [webserver_name]`).

Q3: What happens if I set the wrong ownership with `chown`?

A3: Setting incorrect ownership can lead to a range of issues. Your web server might lose the ability to read your website files (resulting in “403 Forbidden” errors or blank pages), or your application might fail to write to necessary directories (e.g., uploads, cache). In severe cases, changing ownership of critical system files could make your server unstable or unbootable. Always test changes and verify with `ls -l` afterwards.

Q4: Should `wp-config.php` (WordPress) be owned by the web server user?

A4: For `wp-config.php` specifically, best practice often suggests it should be owned by your administrative or SFTP user, not the web server user. The web server user typically only needs read access. This adds an extra layer of security: if the web server process is compromised, the attacker still cannot modify `wp-config.php` because the web server user doesn’t own it. Permissions like `640` or `600` are generally recommended.

Q5: Is `chown` necessary for a newly provisioned VPS?

A5: Absolutely. When you provision a new VPS, files transferred to it might retain ownership from their source. The default user created during OS installation or by your hosting provider will own newly created files. You will almost certainly need to use `chown` to adjust the ownership of your website or application files to the correct web server user and group for proper functionality and security.

Q6: Can `chown` be used to grant access to multiple users for the same files?

A6: `chown` sets a single owner user and a single owner group. To grant access to multiple users, you would typically use `chgrp` to set a common group ownership (e.g., a “developers” group), and then add all relevant users to that group. Then, `chmod` permissions are used to grant read/write access to that group. This way, any user in the group gets the defined permissions.

Mastering the `chown` command is a testament to your commitment to robust and secure server management. It’s not merely a technicality but a foundational element of a resilient online presence. Whether you’re configuring a fresh Netherlands VPS, migrating a critical application to a Dedicated Server, or simply hardening your existing Premium Hosting environment, informed file ownership ensures your digital assets are both functional and protected. Prioritize understanding this command and its interplay with permissions, and you’ll build a more stable, secure, and manageable foundation for your web operations.

When in doubt, always consult your hosting provider’s documentation or support. For complex migrations or advanced configurations, Semayra’s team can provide guidance to ensure your ownership and permission schemes are optimized for security and performance from day one.

Mastering Linux File Ownership: The `chown` Command for Hosting Environments