Docker Nextcloud dosya konumu nerede bulunur?

Nextcloud'un Docker içinde dosyaları nerede sakladığı

Docker içindeki Nextcloud, dosyaları container içindeki bir veri dizininde saklar; sunucunuzdaki gerçek konum ise bağladığınız herhangi bir volume veya bind mount noktasıdır. linuxserver.io imajı kullanıldığında, lscr.io/linuxserver/nextcloud, kullanıcı dosyaları /data dizininde bulunur ve config.php içeren Nextcloud kurulumu ise /config dizininde yer alır. Bunların her ikisi de container içi yollardır. Tek bir komut, bu yolların arkasındaki ana makine (host) yolunu yazdırır; bu kılavuzun geri kalanı ise sorunun daha zor olan kısmını, yani veri dizininin tutmadığı her şeyi kapsar.

İmaj etiketini sabitleyin. Yollar Nextcloud'dan ziyade imaja aittir ve değişken bir etiket, bilginiz dışında değişebilir. Ağustos 2026 itibarıyla bu imaj için güncel kararlı etiket 34.0.3 şeklindedir.

services:
  nextcloud:
    image: lscr.io/linuxserver/nextcloud:34.0.3
    container_name: nextcloud
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
    volumes:
      - nextcloud_config:/config
      - nextcloud_data:/data
    ports:
      - 443:443
    restart: unless-stopped

  nextcloud-db:
    image: mariadb:11.8
    container_name: nextcloud-db
    environment:
      - MARIADB_ROOT_PASSWORD=${MARIADB_ROOT_PASSWORD}
      - MARIADB_DATABASE=nextcloud
      - MARIADB_USER=nextcloud
      - MARIADB_PASSWORD=${NEXTCLOUD_DB_PASSWORD}
    volumes:
      - nextcloud_db:/var/lib/mysql
    restart: unless-stopped

volumes:
  nextcloud_config:
  nextcloud_data:
  nextcloud_db:

İki parola, compose dosyasının yanındaki bir .env dosyasından gelir, böylece compose dosyasının kendisinin dışında tutulurlar. Bu, yanıttaki üç volume anlamına gelir ve bunlardan yalnızca biri kullanıcı dosyalarını tutar.

Bu container yolları, ilgili imajın dokümantasyonundan gelir. Farklı bir Nextcloud imajı, dosya sistemini farklı şekilde düzenler ve kurulumu kendi web kök dizini altında tutar; bu nedenle bir forum gönderisinden kopyalanan yol sadece bir tahmindir. Gerçeği çalıştırdığınız container üzerinden okuyun.

docker inspect nextcloud

Bu çıktının Mounts bölümü, ana makine tarafında Source ve container tarafında Destination olacak şekilde her mount noktasını listeler. Bu liste, hangi imajı seçmiş olursanız olun, kurulumunuz için soruyu yanıtlar.

Bir volume arkasındaki gerçek host yolu nasıl bulunur?

Adlandırılmış bir volume (named volume) Docker tarafından yönetilir, bu nedenle yolunu siz belirlemezsiniz. Yolu sistemden sorgulamanız gerekir.

docker volume ls
docker volume inspect nextcloud_nextcloud_data

İsim önemlidir. Docker Compose, volume isimlerinin başına proje ismini ekler. Proje ismi varsayılan olarak compose dosyanızın bulunduğu dizinin adıdır; bu nedenle dosyada nextcloud_data olarak yazılan bir volume, disk üzerinde genellikle nextcloud_nextcloud_data olarak bulunur. docker volume ls komutu gerçek isimleri gösterir. Inspect çıktısı, kısaltılmış haliyle şu şekildedir:

[
    {
        "CreatedAt": "2026-08-18T09:12:44Z",
        "Driver": "local",
        "Mountpoint": "/var/lib/docker/volumes/nextcloud_nextcloud_data/_data",
        "Name": "nextcloud_nextcloud_data",
        "Scope": "local"
    }
]

Mountpoint cevaptır. Bu yol değişebildiği için varsayımda bulunmak yerine komut çıktısından okuyun. Rootless Docker kurulumunda tüm Docker veri kök dizini, daemon'ı çalıştıran kullanıcının ev dizini içinde yer alır, dolayısıyla bu yol farklı bir konumdan başlar.

Bind mount kullanımı bu soruyu ortadan kaldırır. Compose dosyasında - /srv/nextcloud/data:/data yazarsanız host yolu sizin belirttiğiniz yol olur ve docker inspect bunu Source olarak raporlar. Bu tercih sadece yolu değil, adlandırılmış volume'lar ve bind mount'lar sahiplik ve yedekleme konularında farklı davrandığı için sistemin işleyişini de değiştirir.

Veri dizini neden bir yedek değildir

Nextcloud kılavuzu, bir yedeğin içermesi gereken beş öğeyi listeler: yapılandırma klasörü, özel uygulamalar klasörü, veri klasörü, tema klasörü ve veritabanı. Bu imaj ile yapılandırma, uygulamalar ve tema klasörlerinin tamamı /config altında yer alırken, veritabanı kendi volume alanına sahip ayrı bir container içinde çalışır. Yalnızca /data dizinini kopyalarsanız, sorunun en önemsiz kısmını yedeklemiş olursunuz.

Veritabanı önemlidir çünkü web arayüzü hiçbir zaman bir dizini listelemez. Arayüz, dosya önbelleğindeki satırları listeler; kılavuzun, dosyaları manuel olarak veri dizinine kopyaladıktan sonra bir tarama çalıştırmanızı söylemesinin nedeni budur. /data dizinini boş bir veritabanı ile geri yüklerseniz, elinizde dizini olmayan baytlar kalır: kullanıcılar, paylaşımlar ve dosya listesindeki hiçbir şey görünmez. Veritabanını boş bir /data dizini ile geri yüklerseniz, her satır artık mevcut olmayan bir dosyayı işaret eder.

config.php dosyası, veritabanı kimlik bilgilerini ve güvenilen alan adlarını tutar. Ayrıca, veri dizini içindeki uygulama verileri klasörünün adı olan instance id bilgisini de barındırır. Bu değerleri hafızanızdan hatırlamaya çalışmak yerine, çalışan instance üzerinden sorgulayın.

docker exec -it nextcloud occ config:system:get datadirectory
docker exec -it nextcloud occ config:system:get instanceid

İlk komut, bu instance tarafından fiilen kullanılan veri dizinini yazdırır; burada bu dizin /data'tür. Bu imaj, yol üzerinde bir occ sarmalayıcısı ile gelir, bu nedenle komutu doğrudan docker exec üzerinden çalıştırın. Nextcloud kılavuzunda yer alan ve container dışı kurulumlar için yazılmış olan daha uzun sudo ve php occ biçimlerini kopyalamayın.

Veri birimini sessizce dolduran nedir?

Önizlemeler ve kullanıcı bazlı geçmiş, dosyalarla aynı birimde tutulur ve her ikisi de web arayüzünde kullanıcının gördüğü depolama rakamına yansımaz.

• Önizlemeler, oluşturulmuş küçük resimlerdir. Bunlar, veri dizini içindeki uygulama verisi klasöründe, appdata_ ve ardından gelen örnek kimliği ile adlandırılmış şekilde bulunur.
• Silinen dosyalar çöp kutusunda kalır. trashbin_retention_obligation varsayılan olarak auto değerindedir; bu ayar dosyaları 30 gün boyunca tutar ve ancak alan gerektiğinde siler. Silinen dosyalar kullanıcı kotasından düşmeye devam eder. Kota aşıldığında, saklama ayarı göz ardı edilir ve kota uygun seviyeye gelene kadar çöp kutusu temizlenir.
• Eski sürümler de aynı şekilde saklanır. versions_retention_obligation de varsayılan olarak auto değerindedir. Sürümler uygulaması, kullanıcının o anki boş alanının %50'sinden fazlasını asla kullanmaz. Temizlik yaparken en eski sürümleri siler, en güncel iki sürümü ise korur. Kullanıcının elle adlandırdığı bir sürüm asla silinmez.

Herhangi bir şeyi silmeden önce ölçüm yapın.

docker exec -it nextcloud sh -c 'du -sh /data/*'
docker exec -it nextcloud sh -c 'du -sh /data/appdata_*'

İlk satır, her kullanıcı klasörü ve uygulama verisi klasörü için bir sayı verir. Uygulama verisi sayısı yüksekse, bunun nedeni önizlemelerdir. Aşağıdaki temizleme komutları belgelenmiştir ve her biri verileri bilinçli olarak yok eder.

docker exec -it nextcloud occ trashbin:cleanup --all-users
docker exec -it nextcloud occ versions:cleanup alice
docker exec -it nextcloud occ preview:cleanup

preview:cleanup, oluşturulan tüm önizlemeleri kaldırır. Kullanıcılar dosyaları açtıkça Nextcloud bunları yeniden oluşturur; bu nedenle alan kademeli olarak geri kazanılır ancak CPU kullanımı artar. Birim, daha geniş bir disk sorununun yalnızca bir parçasıysa, eski görseller ve kullanılmayan derleme önbelleği genellikle sorunun diğer kısmını oluşturur.

Sunucuya kopyaladığım dosyalar neden Nextcloud içinde görünmüyor?

Nextcloud dosya önbelleğini dizinden değil, veritabanından okur. Doğrudan diske kopyaladığınız dosyalar için veritabanında eşleşen bir satır bulunmadığından, web arayüzü listeleyecek bir veri bulamaz. Kılavuzda bu durum açıkça belirtilmiştir: dosyalar doğrudan veri dizinine kopyalandıktan sonra bir tarama işlemi yapılması gerekir.

docker exec -it nextcloud occ files:scan --path="/alice/files/Photos"
docker exec -it nextcloud occ files:scan --unscanned -v
docker exec -it nextcloud occ files:scan --all

--path argümanı, veri dizini içindeki yerleşimi de gösterir: her kullanıcının kullanıcı adıyla isimlendirilmiş bir klasörü vardır ve bunun içindeki files dizini, kullanıcının web arayüzünde gördüğü dosyaları barındırır. Dosyaların nereye kopyalandığını biliyorsanız ilgili yolu taratın. --all komutu tüm kullanıcıları tarar ve büyük bir kurulumda uzun sürer. --unscanned komutu ise yalnızca henüz tam olarak taranmamış olarak işaretlenmiş dosyalara işlem yapar. -v komutu, her dosyayı işlendikçe ekrana yazdırır; bu, komutun takılıp kalması ile izlenebilir olması arasındaki farkı yaratır.

Dosya sahipliği, tarama işleminin yeterli olup olmayacağını belirler. Container kullanıcısının yazma yetkisi olmayan bir dosya dizine eklense bile taşınamaz; bu durumda liste doğru görünse de web arayüzünden yapılan yeniden adlandırma veya silme işlemleri başarısız olur.

PUID ve PGID ayarlandıktan sonra yazma işlemleri neden başarısız oluyor?

Çekirdek, isimleri değil sayıları karşılaştırır. PUID ve PGID, container sürecinin çalışacağı sayısal kullanıcı kimliğini (uid) ve grup kimliğini (gid) belirler. Ana makinedeki (host) her dosyanın da sayısal bir sahibi vardır. Bu iki sayı birbirinden farklı olduğunda, isimler her iki tarafta nasıl görünürse görünsün yazma işlemi reddedilir.

docker exec -it nextcloud id abc
sudo ls -ln /var/lib/docker/volumes/nextcloud_nextcloud_data/_data

id abc, container'ın gerçekten kullandığı ve sizin PUID/PGID olarak atadığınız uid ve gid değerlerini yazdırır. ls -ln sayısal sahipleri yazdırır ve -n burada önemlidir: düz ls -l, bu sayıları ana makinenin kendi kullanıcı listesi üzerinden çevirir ve container içinde hiçbir anlam ifade etmeyen bir isim gösterir. İki sayıyı karşılaştırın.

Ardından tahmin yürütmek yerine yazma işlemini test edin.

docker exec -u abc -it nextcloud touch /data/writetest

/data belirten bir Permission denied, işlemin onaylandığını gösterir. Sahiplik yetkisini container içinden düzeltin ve testi tekrar çalıştırın.

docker exec -u 0 -it nextcloud chown -R abc:abc /data
docker exec -u abc -it nextcloud touch /data/writetest
docker exec -u abc -it nextcloud rm /data/writetest

Bunu içeriden yapmanızın bir nedeni var. Rootless Docker altında container kullanıcı kimlikleri, /etc/subuid içindeki alt aralıklar (subordinate range) üzerinden eşlenir; bu nedenle container içindeki uid 1000, ana makinede çok daha yüksek bir uid değerine karşılık gelir. Ana makine tarafında çalıştırılan bir chown 1000:1000, container'ın kullanamayacağı bir sahip atar ve yazma işlemi yine başarısız olur. chown komutunu container içinde çalıştırmak, Nextcloud sürecinin kendisinin kullandığı eşleme üzerinden ilerler; böylece sayılar yapısal olarak birbirine uyumlu hale gelir. Başka bir hata ayıklama işlemine başlamadan önce PUID ve PGID değerlerinin disk üzerindeki sahip ile eşleşmesi gerektiğinin nedeni de budur.

Yedekleme işleminin geri yüklemede çalışması nasıl sağlanır?

Veritabanını ve klasörleri aynı zaman diliminde yedekleyin. Bakım modu girişleri durdurur; böylece dump ve kopyalama işlemleri arasında yeni bir veri girişi gerçekleşmez.

docker exec -it nextcloud occ maintenance:mode --on
docker exec nextcloud-db mariadb-dump --single-transaction -u nextcloud -p"$NEXTCLOUD_DB_PASSWORD" nextcloud > nextcloud-sqlbkp.sql
docker run --rm -v nextcloud_nextcloud_data:/data:ro -v "$PWD":/backup alpine:3.22 tar czf /backup/nextcloud-data.tgz -C /data .
docker run --rm -v nextcloud_nextcloud_config:/config:ro -v "$PWD":/backup alpine:3.22 tar czf /backup/nextcloud-config.tgz -C /config .
docker exec -it nextcloud occ maintenance:mode --off

Dump komut satırında bulunmayan bir detaya dikkat edin: -t bayrağı. TTY, satır sonlarını yeniden yazar; bu süreçten geçen bir SQL dump, ancak geri yükleme sırasında fark edilebilecek şekilde bozulur. Ayrıca, komut satırına yazılan bir parolanın komut çalışırken ps çıktısında görüneceğini unutmayın; bu nedenle parolayı yazmak yerine .env dosyanızdan shell ortamına aktarın. Eski veritabanı imajları mariadb-dump yerine mysqldump ile gelir; kılavuz her ikisini de belgeler.

Geri yükleme yapmak için dump dosyasını boş bir veritabanına yükleyin, her iki arşivi de temiz birimlere (volume) açın, container'ları başlatın ve ardından bakım modunu kapatın. Klasörler ve dump dosyası farklı zamanlara aitse, dosya önbelleği ile disk verileri uyumsuz hale gelir ve occ files:scan --all yalnızca tek yönlü onarım yapabilir. Bu araç, veritabanı kaydı olmayan dosyaları bulur ancak bir kaydın işaret ettiği ancak silinmiş olan dosyayı geri getiremez.

Yedekleri sunucu dışında tutun. Aynı VPS içinde tutulan bir kopya, VPS ile birlikte yok olur; bu nedenle sunucu dışı bir depoya restic ile yedekleme bu döngünün bir parçası olmalıdır ve sağlayıcı snapshot'ı ile yedekleme farklı araçlardır. Eğer henüz altyapıyı kuruyorsanız, VPS üzerinde tam Nextcloud kurulumu rehberi, bu kılavuzun kapsamı dışında kalan reverse proxy ve TLS (transport layer security) sertifikası konularını ele almaktadır.

FAQ

Docker konteyneri içindeki Nextcloud veri dizini nerededir?

linuxserver.io imajı ile bu dizin konteyner içinde /data konumundadır ve config.php ile yapılan kurulumda /config altındadır. Bunlar konteyner içi yollardır. Ana makine (host) üzerindeki yolu bulmak için docker inspect nextcloud komutunu çalıştırın ve Mounts bölümündeki Source değerini okuyun veya volume üzerinde docker volume inspect komutunu çalıştırıp Mountpoint değerini inceleyin. Diğer Nextcloud imajları farklı konteyner yolları kullanır; bu nedenle sabitlediğiniz etiketin (tag) dokümantasyonunu kontrol edin ve docker exec -it nextcloud occ config:system:get datadirectory ile doğrulayın.

Volume içine kopyaladığım dosyalar neden Nextcloud içinde görünmüyor?

Nextcloud, dizini okumak yerine veritabanındaki dosya önbelleğinden satırları listeler; bu nedenle Nextcloud üzerinden geçmeyen bir dosyanın veritabanında kaydı yoktur ve görünmez kalır. Tek bir klasör için docker exec -it nextcloud occ files:scan --path="/alice/files/Photos", tüm kullanıcılar için ise occ files:scan --all komutunu çalıştırın. Dosyalar görünmesine rağmen taşınamıyor veya silinemiyorsa, sorun sahiplik (ownership) kaynaklıdır: konteyner kullanıcısının bu dosyalara yazma yetkisi olmalıdır.

Nextcloud'u geri yüklemek için veri volume'ünün bir kopyası yeterli midir?

Hayır. Veri volume'ü yalnızca dosya içeriğini tutar. Veritabanı; dosya dizinini, kullanıcıları ve paylaşımları barındırır; config.php ise veritabanı kimlik bilgilerini ve instance id değerini içerir. Çalışan bir geri yükleme işlemi için veri klasörü, yapılandırma (config) klasörü, veritabanı ve kullanıyorsanız özel uygulamalar ile tema klasörleri gereklidir. Bunların hepsini aynı zaman diliminden alın; çünkü dosyalardan daha yeni bir veritabanı, mevcut olmayan dosyaları işaret eder.

Veri volume'üm neden kullanıcıların gördüğü dosyalardan çok daha büyük?

Önizlemeler, silinen dosyalar ve eski sürümler aynı volume içinde yaşar ve hiçbiri kullanıcının gördüğü toplam boyuta dahil edilmez. Boyutu docker exec -it nextcloud sh -c 'du -sh /data/*' ile ölçün. Çöp kutusu, silinen dosyaları varsayılan olarak 30 gün tutar ve yalnızca alan gerektiğinde temizler; Sürümler (Versions) uygulaması ise kullanıcının mevcut boş alanının yarısına kadarını kullanabilir. Bunları occ trashbin:cleanup --all-users, occ versions:cleanup alice ve occ preview:cleanup ile temizleyin; kullanıcılar dosyalarını açtıkça önizlemelerin tekrar büyüyeceğini unutmayın.

Nextcloud veri dizinini başka bir diske taşıyabilir miyim?

Nextcloud'un bildiği yolu değiştirmek yerine, yeni konumu aynı konteyner yoluna bağlayın (mount). Konteyneri durdurun, eski içeriği sahiplik bilgilerini koruyarak (cp -a veya rsync -aAX) yeni diske kopyalayın, compose dosyanızdaki volume veya bind mount tanımını yeni konuma yönlendirin ve ardından konteyneri tekrar başlatın. Nextcloud hala /data yolunu gördüğü için veritabanındaki hiçbir satırın değişmesi gerekmez. docker exec -it nextcloud occ config:system:get datadirectory ve bir test yüklemesi ile durumu doğrulayın.