How to Correctly Transfer File Ownership from root to a User in DirectAdmi

[Aior]

DirectAdmin sunucularında root yetkisiyle yapılan kopyalama veya açma işlemleri sonrasında, kullanıcının dosyalarına web sunucusu süreçleri ulaşamadığında klasik 403, 500 ve File Manager hataları görülür. Bunun sebebi neredeyse her zaman aynıdır: dosya/dizin sahipliği root:root kalmış ve kullanıcı kendi ana dizinindeki içeriği okuyamıyordur. DirectAdmin tarafında bu durumu düzeltmek hem güvenlik hem de tutarlılık açısından kritiktir.

Doğru kullanıcı ve grup adı
DirectAdmin'de bir hesap için kullanıcı adı ile grup adı aynıdır. Yani aiortest kullanıcısının dosya sahipliği aiortest:aiortest olmalıdır. Eğer site PHP-FPM ile çalışıyorsa havuz, kullanıcı adına çalışır; Apache mod_php veya suPHP altında da kullanıcı sahipliği temel beklentidir.

1) Hızlı düzeltme: tek komut
Çoğu durumda kullanıcının evindeki tüm içerik için yapılacak iş şudur:

chown -R aiortest:aiortest /home/aiortest

Bu komut hem dosyaları hem dizinleri kapsar. Ancak /home/aiortest altındaki domains/, Maildir/, imap/, backups/ gibi alt klasörlerin tamamı tek seferde dönüşür; bu nedenle değiştirmeden önce dizinin kullanıcıya ait olması gerektiğinden emin olun.

2) Sadece public_html altına uygulamak
Yalnız belirli bir alan için düzeltme yapılacaksa:

chown -R aiortest:aiortest /home/aiortest/domains/aiorornek.com/public_html

Bu, mail dizinlerini ve hesap altyapısını etkilemeden web içeriğini tutarlı hâle getirir.

3) İzinleri de standardize edin
Sahiplik düzeltildikten sonra çoğu zaman izinler de tutarsız kalır. DirectAdmin'in beklediği güvenli temel:

find /home/aiortest/domains/aiorornek.com/public_html -type d -exec chmod 755 {} \;
find /home/aiortest/domains/aiorornek.com/public_html -type f -exec chmod 644 {} \;

Yazılabilir olması gereken dizinler (örneğin uploads, cache) için spesifik chmod 775 kuralları uygulayın; 777 verme alışkanlığından kaçının.

4) Suspicious bayrak ve immutable nitelikleri
Bazı durumlarda chattr +i ile değiştirilmez işaretli dosyalar görülür. lsattr ile kontrol edin, gerekirse chattr -i ile kaldırın. ImunifyAV/Imunify360 karantinası ile karıştırmayın; karantinaya alınmış bir dosya panelinden geri yüklenmelidir.

5) Açık dosyaları olan dizinler
Mail veya FTP süreçleri açıkken sahiplik değiştirmek genellikle güvenlidir; ancak rsync devam ediyorsa beklenmedik sonuçlar doğurabilir. Önce ps aux | grep aiortest ile aktif süreçleri kontrol edin.

6) Doğrulama

stat /home/aiortest/domains/aiorornek.com/public_html/index.php
namei -l /home/aiortest/domains/aiorornek.com/public_html

İkinci komut, kök dizinden hedefe kadar tüm bileşenlerin sahip/izin durumunu gösterir; izin hatalarını teşhis etmek için en hızlı yoldur.

7) Önleyici yaklaşım
root altında tarball açtığınızda öncelikle su - aiortest ile kullanıcı oturumuna geçin veya tar --no-same-owner kullanın. Yedek geri yüklemelerinde DirectAdmin'in admin restore aracını tercih edin; bu araç sahiplikleri kullanıcıya göre kurar.

Bu kurallarla web sitesi 403 veya beyaz ekran hatası vermez; mail sunucusu Maildir dizinlerine erişebilir ve FTP/SFTP kullanıcıları kendi dosyalarını düzgün biçimde değiştirebilir.

When file operations on a DirectAdmin server are done as root — extracting a tarball, restoring a backup, copying files into a user's home — the resulting permissions often leave content owned by root:root. The user, the web server worker and PHP-FPM can no longer read the files, producing the classic 403, 500 and "empty" File Manager symptoms. Fixing it is straightforward but easy to get subtly wrong, so this is the reference workflow.

Correct user and group naming
On DirectAdmin the user and group share the same name. A user called aiortest should own files as aiortest:aiortest. If the site is served by PHP-FPM, the pool runs as that user; under suPHP or mod_ruid2 the same expectation holds. The ownership has to match for the web stack to function.

1) The quick fix
In most cases the right command is exactly:

chown -R aiortest:aiortest /home/aiortest

This rewrites every file and directory under the user's home. Be aware that the recursion sweeps into domains/, Maildir/, imap/ and backups/ too, so first confirm none of those subtrees legitimately need a different owner.

2) Scoping to a single document root
If you only want to touch one domain:

chown -R aiortest:aiortest /home/aiortest/domains/example.com/public_html

This keeps mail directories and account infrastructure untouched while making the web content consistent.

3) Normalise permissions too
Ownership alone is rarely enough — permissions are usually scrambled as well. DirectAdmin's expected baseline is:

find /home/aiortest/domains/example.com/public_html -type d -exec chmod 755 {} \;
find /home/aiortest/domains/example.com/public_html -type f -exec chmod 644 {} \;

Apply targeted 775 on writable directories like uploads/ or cache/, and resist the temptation to use 777 anywhere — Imunify360 will flag it and CloudLinux will isolate it.

4) Immutable flags
Occasionally files are flagged immutable with chattr +i. Check with lsattr and clear with chattr -i where appropriate. Do not confuse that with ImunifyAV/Imunify360 quarantine; quarantined files have to be restored from the security panel, not chowned back.

5) Files with active handles
Changing ownership while mail or FTP processes are running is normally safe, but interrupting an rsync mid-flight is not. Run ps aux | grep aiortest before sweeping the home directory and avoid touching a path that an ongoing job depends on.

6) Verification

stat /home/aiortest/domains/example.com/public_html/index.php
namei -l /home/aiortest/domains/example.com/public_html

The second command walks every component from / down to your target and prints the owner and mode of each one — by far the fastest way to spot a wrong perm three directories up the tree.

7) Preventing the problem next time
When you need to extract content into a user's home as root, switch to the account first with su - aiortest or pass tar --no-same-owner. For backup restores, prefer DirectAdmin's admin restore tool — it sets ownership from the user record automatically. Following these rules removes the entire class of "site returns 403 but the file is right there" bugs.