[RESOLU]Owncloud : déplacement du dossier data

Lupa · 02-04-2022 10:32:56

Bonjour à tous :hello:

J'ai remonté mon serveur Apache. Il fonctionne nickel, et en https. Oui, mais...

Lorsque je l'avais précédemment monté, j'avais suivi cette procédure :

https://www.extrem-network.com/2015/12/ … oire-data/

Moi, j'avais mis le dossier data de owncloud sur le /media/data. Ca fonctionnait.

Maintenant, elle ne marche pas.

J'ai aussi suivi celle-là :

https://mondedie.fr/d/6435-astuce-chang … -downcloud

Marche pas non plus.

J'ai cette cette erreur au lancement de Firefox sur l'IP locale du serveur : (je n'arrive pas à uploader sur Securityx, désolé) :
https://cjoint.com/c/LDciS7zIAMj

Pourtant :

root@1150-SRV:/mnt# ls -l ./DONNEES/ocdata
total 12K
drwxrwx--- 6 www-data www-data 4,0K mars 30 13:21 data
drwxr-xr-x 3 www-data www-data 4,0K avril 2 11:05 .
drwxr-xr-x 5 www-data www-data 4,0K avril 2 11:05 ..

Extrait de mon /etc/apache2/apache2.conf :

<Directory />

  Options FollowSymLinks

  AllowOverride None

  Require all denied

</Directory>

<Directory /usr/share>

  AllowOverride None

  Require all granted

</Directory>

<Directory /var/www/>

  # ==>> pour éviter le warning de apache2ctl -S

        #Options Indexes FollowSymLinks MultiViews 

  AllowOverride all

  # Require all granted

        Satisfy Any

</Directory>

<Directory /mnt/DONNEES/ocdata/data>

  # ==>> pour éviter le warning de apache2ctl -S

        Options Indexes FollowSymLinks MultiViews 

  AllowOverride all

   Require all granted

        Satisfy Any

</Directory>

Le config.php :

<?php

$CONFIG = array (

  'instanceid' => 'oc3204klngo7',

  'passwordsalt' => 'lS1yqxqIhEwp7wIIJxrPmpDhJXYMAm',

  'secret' => 'vshQa4xHcoibxnA8i1u0I4UwOWJLsK+TWEaK/Dpu4hAQ/huR',

  'trusted_domains' => 

  array (

    0 => 'localhost',

    1 => '192.168.0.51',

    2 => 'IP publique',

  ),

  'datadirectory' => '/var/mnt/DONNEES/ocdata/data',

  'overwrite.cli.url' => 'http://192.168.0.51',

  'dbtype' => 'mysql',

  'version' => '10.9.1.2',

  'dbname' => 'owncloud',

  'dbhost' => 'localhost:3306',

  'dbtableprefix' => 'oc_',

  'mysql.utf8mb4' => true,

  'dbuser' => 'oc_root',

  'dbpassword' => 'SY4eaUPESfo5lCM0dEt/WUzm22Q1qF',

  'allow_user_to_change_mail_address' => '',

  'logtimezone' => 'UTC',

  'apps_paths' => 

  array (

    0 => 

    array (

      'path' => '/var/www/owncloud/apps',

      'url' => '/apps',

      'writable' => false,

    ),

    1 => 

    array (

      'path' => '/var/www/owncloud/apps-external',

      'url' => '/apps-external',

      'writable' => true,

    ),

  ),

  'installed' => true,

  'forcessl' => true,

);

Tout est au vert côté apache :

root@1150-SRV:~# service apache2 status

● apache2.service - The Apache HTTP Server

   Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)

   Active: active (running) since Sat 2022-04-02 11:17:33 CEST; 5s ago

     Docs: https://httpd.apache.org/docs/2.4/

  Process: 2045 ExecStart=/usr/sbin/apachectl start (code=exited, status=0/SUCCESS)

 Main PID: 2049 (apache2)

    Tasks: 6 (limit: 4915)

   Memory: 14.8M

   CGroup: /system.slice/apache2.service

           ├─2049 /usr/sbin/apache2 -k start

           ├─2050 /usr/sbin/apache2 -k start

           ├─2051 /usr/sbin/apache2 -k start

           ├─2052 /usr/sbin/apache2 -k start

           ├─2053 /usr/sbin/apache2 -k start

           └─2054 /usr/sbin/apache2 -k start

avril 02 11:17:33 1150-SRV systemd[1]: Starting The Apache HTTP Server...

avril 02 11:17:33 1150-SRV systemd[1]: Started The Apache HTTP Server

root@1150-SRV:~# apache2ctl configtest

Syntax OK

root@1150-SRV:~# apache2ctl -S

VirtualHost configuration:

*:443                  localhost (/etc/apache2/sites-enabled/owncloud.conf:1)

ServerRoot: "/etc/apache2"

Main DocumentRoot: "/var/www/html"

Main ErrorLog: "/var/log/apache2/error.log"

Mutex default: dir="/var/run/apache2/" mechanism=default 

Mutex mpm-accept: using_defaults

Mutex watchdog-callback: using_defaults

Mutex ssl-stapling-refresh: using_defaults

Mutex ssl-stapling: using_defaults

Mutex ssl-cache: using_defaults

PidFile: "/var/run/apache2/apache2.pid"

Define: DUMP_VHOSTS

Define: DUMP_RUN_CFG

User: name="www-data" id=33

Group: name="www-data" id=33

Seulement ce truc qui me tracasse, mais le serveur fonctionne quand-même :

root@1150-SRV:~# apache2ctl status

/usr/sbin/apache2ctl: 113: /usr/sbin/apache2ctl: www-browser: not found

'www-browser -dump http://localhost:80/server-status' failed.

Maybe you need to install a package providing www-browser or you

need to adjust the APACHE_LYNX variable in /etc/apache2/envvars

Là, j'ai besoin de vos lumières.
Je suis coincé.
Merci

Je précise tout de même que j'ai parcouru et traduit je ne sais combien de pages web. Mais je ne trouve pas la réponse...

Dernière modification par Lupa (06-04-2022 11:18:49)

dejieres · 02-04-2022 10:39:52

Bonjour,

J'utilise plus Nextcloud qu'Owncloud, mais bon, ils sont relativement proches.

Tu as vérifié la présence du fichier caché /var/mnt/DONNEES/ocdata/data/.ocdata ?

raleur · 02-04-2022 11:59:31

Lupa a écrit :

j'avais mis le dossier data de owncloud sur le /media/data

/media n'est pas fait pour ça. Cf. FHS.

Lupa a écrit :

root@1150-SRV:/mnt# ls -l ./DONNEES/ocdata

/mnt non plus.

Lupa a écrit :

<Directory /mnt/DONNEES/ocdata/data>
...
'datadirectory' => '/var/mnt/DONNEES/ocdata/data'

Normal que le chemin soit différent ?

Dernière modification par raleur (02-04-2022 12:00:47)

Lupa · 02-04-2022 12:14:38

Bonjour !

@dejieres : je vérifie ça tout de suite.

@raleur : je n'avais pas vu ça. Je regarde.

Mais : où le monter, alors ? Je ne veux pas utiliser le SSD système.
1/ parce que les datas sont trop lourdes pour réaliser une image rapidement, avant les mises à jour.
2/ Sur quoi le monter, ce dossier data, étant donné qu'il doit être sur le SECOND SSD.

Lupa · 02-04-2022 12:21:03

Voilà :
1/ oui : le .ocdata est dans le répertoire /mnt/DONNEES/ocdata/data.ocdata
0 octets. est vide.

2/ Ahhhh !!! Je me suis trompé de path !!

Lupa · 02-04-2022 12:28:01

Corrigé le config.php :

<?php

$CONFIG = array (

  'instanceid' => 'oc3204klngo7',

  'passwordsalt' => 'lS1yqxqIhEwp7wIIJxrPmpDhJXYMAm',

  'secret' => 'vshQa4xHcoibxnA8i1u0I4UwOWJLsK+TWEaK/Dpu4hAQ/huR',

  'trusted_domains' => 

  array (

    0 => 'localhost',

    1 => '192.168.0.51',

    2 => 'IP publique',

  ),

#  'datadirectory' => '/var/www/owncloud/data',

[b]  'datadirectory' => '/mnt/DONNEES/ocdata/data',[/b]

  'overwrite.cli.url' => 'http://192.168.0.51',

  'dbtype' => 'mysql',

  'version' => '10.9.1.2',

  'dbname' => 'owncloud',

  'dbhost' => 'localhost:3306',

  'dbtableprefix' => 'oc_',

  'mysql.utf8mb4' => true,

  'dbuser' => 'oc_root',

  'dbpassword' => 'SY4eaUPESfo5lCM0dEt/WUzm22Q1qF',

  'allow_user_to_change_mail_address' => '',

  'logtimezone' => 'UTC',

  'apps_paths' => 

  array (

    0 => 

    array (

      'path' => '/var/www/owncloud/apps',

      'url' => '/apps',

      'writable' => false,

    ),

    1 => 

    array (

      'path' => '/var/www/owncloud/apps-external',

      'url' => '/apps-external',

      'writable' => true,

    ),

  ),

  'installed' => true,

  'forcessl' => true,

);

Oui : le .ocdata existe bien à la racine du dossier /mnt/DONNEES/ocdata/data
Et il porte la date de l'installation. Mais il est vide.

Mais j'ai le même message côté serveur.

On dirait que Owncloud veut CREER ce fichier, comme il le fait lors de l'installation. Pourquoi ?

Je reviens à l'image CloneZilla réalisée avant le déplacement du dossier. Je veux voir ce qu'il y avait dans ce fichier .ocdata

Dernière modification par Lupa (02-04-2022 12:33:10)

dejieres · 02-04-2022 12:56:53

en principe, il n'y a rien dans ce fichier. Il sert juste d'indicateur.

Lupa · 02-04-2022 13:29:00

J'ai vérifié : il portait la date de création de la base.

Et même message de Owncloud côté serveur. Et impossible, bien sûr, de connecter le client owncloud.

Il n'y aurait pas un truc à faire dans la base elle-même ? Avec

mysql -uroot -p

 

Virer la base owncloud et la re-créer ? Aïe ! Dangereux, ça...

dejieres · 02-04-2022 14:17:53

Pour la base de données, s'il n'y a pas eu de changement de version, une réindexation devrait suffire. Mais je n'ai pas l'impression que le problème vienne de là.

Vérifie bien l'appartenance des dossiers.

Si ton point de montage est /mnt/DONNEES, le propriétaire de DONNEES devrait être www-data, et pareil pour toute l'arborescence sous DONNEES

Lupa · 02-04-2022 14:42:09

Ahhh...
Je n'avais mis QUE le ocdat/data dans les permissions de www-data
Donc, www-data n'avait pas la permission d'aller en racine de /mnt/DONNEES

Je reviens en arrière et re-déplace le dossier data.

Par ailleurs : owncloud me disant que le dossier data n'est pas vie (cf. l'image), je l'ai viré. Sans résultat.
Je reviens à l'image du 31, juste avant le déplacement.

On va bien s'en sortir, quand-même

dejieres · 02-04-2022 15:44:12

J'ai l'impression que l'erreur de la copie d'écran de ton premier message était essentiellement due au mauvais chemin déclaré dans le config.php. Et lorsque OC ne trouve pas le répertoire data, il tente simplement de le recréer.

Avec le bon chemin dans le config.php, et les bons droits sur l'arborescence, ça devrait rouler.

Lupa · 02-04-2022 15:56:27

Hélas, non !

J'ai tenté de déplacer le répertoire entier de owncloud.
Appliqué dessus les droits de www-data

chown -R www-data-:www-data /mnt/DONNEES/

chmod -R u=rwX /mnt/DONNEES/  # Inutile ? Peut-être

Cponfig.php :

<?php

$CONFIG = array (

  'instanceid' => 'oc3204klngo7',

  'passwordsalt' => 'lS1yqxqIhEwp7wIIJxrPmpDhJXYMAm',

  'secret' => 'vshQa4xHcoibxnA8i1u0I4UwOWJLsK+TWEaK/Dpu4hAQ/huR',

  'trusted_domains' => 

  array (

    0 => 'localhost',

    1 => 'IP publique',

    2 => '82.66.155.194',

  ),

#  'datadirectory' => '/var/www/owncloud/ocdata/data',

  'datadirectory' => '/mnt/DONNEES/owncloud/data',

  'overwrite.cli.url' => 'http://192.168.0.51',

  'dbtype' => 'mysql',

  'version' => '10.9.1.2',

  'dbname' => 'owncloud',

  'dbhost' => 'localhost:3306',

  'dbtableprefix' => 'oc_',  # [b]Là aussi : à modifier ? Je ne l'ai jamais fait.[/b]

  'mysql.utf8mb4' => true,

  'dbuser' => 'oc_root',

  'dbpassword' => 'SY4eaUPESfo5lCM0dEt/WUzm22Q1qF',

  'allow_user_to_change_mail_address' => '',

  'logtimezone' => 'UTC',

  'apps_paths' => 

  array (

    0 => 

    array (

      'path' => '/var/www/owncloud/apps', # [b]Je m'aperçois de ça. Je vais corriger[/b].

      'url' => '/apps',

      'writable' => false, #[b]Pourquoi à false ?[/b]

    ),

    1 => 

    array (

      'path' => '/var/www/owncloud/apps-external', # [b]Je m'aperçois de ça. Je vais corriger[/b].

      'url' => '/apps-external',

      'writable' => true,

    ),

  ),

  'installed' => true,

  'forcessl' => true,

);

Les <Directory> du apache2.conf :

<Directory />

  Options FollowSymLinks

  AllowOverride None

  Require all denied

</Directory>

<Directory /usr/share>

  AllowOverride None

  Require all granted

</Directory>

[b]# Commenté ces lignes :[/b]

#<Directory /var/www/>

  # ==>> pour éviter le warning de apache2ctl -S

        #Options Indexes FollowSymLinks MultiViews 

  #AllowOverride all

  # Require all granted

   #     Satisfy Any

#</Directory>

# ==>> Rajouté ceci :

<Directory /mnt/DONNEES/owncloud/>

  # ==>> pour éviter le warning de apache2ctl -S

        #Options Indexes FollowSymLinks MultiViews 

        AllowOverride all

  # Require all granted

        Satisfy Any

</Directory>

Pour l'instant, j'ai un forbidden (côté serveur). Côté client, sans doute aussi, forcément.
Je vais corriger.

raleur · 02-04-2022 16:03:40

Lupa a écrit :

Mais : où le monter, alors ?

La question à te poser n'est pas "où le monter ?" mais plutôt "où mettrais-je les données qu'il contient si elles n'étaient pas sur un disque séparé ?". Le chemin d'accès doit être défini en fonction du contenu, pas du contenant.

Tu as l'embarras du choix : quelque part dans /srv puisque ce sont des données de serveur, /var/www (historique) puisque ce sont des données de site web, voire /var/lib/owncloud puisque ce sont des données d'owncloud...

Dernière modification par raleur (02-04-2022 16:05:39)

Lupa · 02-04-2022 16:22:41

Oui, mais... Le problème reste entier : comment faire pour que les données de owncloud ne soient pas sur le disque système ?
C'est là que je ne comprends pas.

Un lien symbolique, peut-être, vers le dd d'1 To ? C'est l'une de ses partitions que j'utilisais avant, pour y mettre les données des users de owncloud.

Je ne comprends pas bien : problème de contenu/problème de contenant...

dejieres · 02-04-2022 16:28:03

Lupa a écrit :

chown -R www-data-:www-data /mnt/DONNEES/

c'est une faute de recopie, le tiret à la fin du premier www-data ?

Lupa a écrit :

comment faire pour que les données de owncloud ne soient pas sur le disque système

Ce n'est pas parce que le point de montage apparaît dans l'arborescence système que les données y sont également.

Contrairement à Windows qui a tendance à séparer les périphériques (C:, D:, E:), Linux présente tout sous la même racine. Mais /srv/DONNEES pointera bien vers un périphérique différent du disque système.
Bon, on peut faire ça aussi sous Windows, mais ce n'est pas le sujet

Dernière modification par dejieres (02-04-2022 16:28:57)

Lupa · 02-04-2022 16:41:38

1/ Oui : je n'ai pas mis de tiret. Je ne pense pas que l'OS l'aurait accepté

2/ J'apprends beaucoup, là !

Si je comprends bien, le dossier data de owncloud doit être déplacé dans le /srv/DONNEES . Bon. Mais où va-t-il atterrir, finalement ?
Je veux dire : physiquement : les données de mes users seront bien sur le /mnt/DONNEES ?
Sans rien faire d'autre ? Pas même le déplacement physique du dossier ?

Ai-je bien compris ?

Dernière modification par Lupa (02-04-2022 16:42:32)

raleur · 02-04-2022 16:47:23

Lupa a écrit :

comment faire pour que les données de owncloud ne soient pas sur le disque système ?

Tu montes l'autre disque à l'emplacement choisi, tout simplement. Comme tu le fais pour /home lorsque c'est une partition séparée par exemple.

Lupa a écrit :

le dossier data de owncloud doit être déplacé dans le /srv/DONNEES

Non, il n'y a rien à déplacer. Il suffit de monter le disque sur /srv/DONNEES au lieu de /mnt/DONNEES par exemple.

Lupa a écrit :

physiquement : les données de mes users seront bien sur le /mnt/DONNEES ?

Cette phrase ne veut rien dire. /mnt/DONNEES est un chemin logique, pas un emplacement physique.

Dernière modification par raleur (02-04-2022 16:50:49)

dejieres · 02-04-2022 16:47:47

Je vais essayer de détailler un peu (raleur complétera ou me corrigera

)

Si tu crées un dossier /mnt/DONNEES sur ton disque système (disons /dev/sda) et que tu déplaces tes données dans ce dossier, elles seront sur sda.

Si par contre tu montes ton disque supplémentaire (appelons-le /dev/sdb) dans le dossier /srv/DONNEES, à l'aide la commande mount, ou par l'intermédiaire du fichier fstab, alors tes données iront sur sdb. Mais elles seront vues à travers le dossier /srv/DONNEES.

Lupa · 02-04-2022 18:09:26

Ah ! Je commence à voir plus clair

voici mon fstab :

# /etc/fstab: static file system information.

#

# Use 'blkid' to print the universally unique identifier for a

# device; this may be used with UUID= as a more robust way to name devices

# that works even if disks are added and removed. See fstab(5).

#

# <file system> <mount point>   <type>  <options>       <dump>  <pass>

# / was on /dev/sda1 during installation

UUID=4b0c937b-eb1c-46b9-bed9-23932e9c6943 /               ext4    errors=remount-ro 0       1

# swap was on /dev/sda5 during installation

UUID=4abdeb87-995c-4045-82d5-9a04536a52d6 none            swap    sw              0       0

/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0

LABEL=DATA  /mnt  ext4  defaults  0 0

LABEL=DONNEES /mnt/DONNEES  ext4  defaults  0 0

Donc, je démonte cette partition /mnt/DONNEES, pour la remonter ensuite sur /svr/DONNEES ...
Le second disque a trois partitions :
DATA : réservée à root pour mes sauvegardes de root. Montée au démarrage sur le /mnt . Réservée à root. Un simple chmod o= -rw
IMAGES : pour les images CloneZilla. Non montée au démarrage mais réservée à root. Là aussi, un chmod -rw
DONNEES : pour les données du serveur. Montée également au démarrage.

Dernière modification par Lupa (02-04-2022 18:11:20)

raleur · 02-04-2022 18:26:14

Lupa a écrit :

DATA : réservée à root pour mes sauvegardes de root. Montée au démarrage sur le /mnt

Rien ne devrait être monté sur ou dans /mnt par /etc/fstab. Ce n'est pas fait pour ça.

Lupa a écrit :

Réservée à root. Un simple chmod o= -rw

Avec ça apache/www-data ne risque pas d'accéder à ce qu'il y a dedans...

dejieres · 02-04-2022 18:29:28

oui, j'ai un peu mélangé dans mon message précédent, entre /mnt et /srv.

Le but était de préciser sur quel support physique se trouveront tes données, point sur lequel tu semblais avoir un doute.

Si ton point de montage a le bon propriétaire, et que tout ça correspond au chemin dans config.php, ça devrait marcher

Lupa · 02-04-2022 18:32:10

Pardon : je me suis mal exprimé.
La partition DATA n'a rien à voir avec celle que j'ai appelée DONNEES.
/mnt/DATA est réservé à root.
MAIS la partition nommée "DONNEES", non, évidemment. Surtout pas !

raleur · 02-04-2022 18:44:01

Lupa a écrit :

La partition DATA n'a rien à voir avec celle que j'ai appelée DONNEES.
/mnt/DATA est réservé à root.
MAIS la partition nommée "DONNEES", non, évidemment. Surtout pas !

C'est bien le problème. Tu as monté DONNEES dans l'arborescence de DATA alors que ça n'a rien à y faire, indépendamment du fait que tu as monté DATA sur /mnt. Du coup pour accéder à DONNEES il faut accéder à DATA.

Une commande simple pour afficher l'emplacement physique et le point de montage correspondant d'un fichier ou répertoire :

df /chemin/vers/le/fichier

Dernière modification par raleur (02-04-2022 18:47:11)

Lupa · 02-04-2022 19:41:29

Eh : Ouais...

root@1150-SRV:~# df /mnt/DONNEES

Sys. de fichiers blocs de 1K  Utilisé Disponible Uti% Monté sur

/dev/sdb1          256614804 23484324  220025484  10% /mnt

root@1150-SRV:~# df /mnt/DATA

Sys. de fichiers blocs de 1K  Utilisé Disponible Uti% Monté sur

/dev/sdb1          256614804 23484324  220025484  10% /mnt

Deux partitions ont le même point de montage.

Alors qu'il me faut monter la partition nommée DONNEES sur /srv/

Je l'avais fait, il y a quelques minutes, mais c'était comme un miroir. Le /srv affichait tout le répertoire de owncloud, exactement comme un

ls /var/www/owncloud

 

Je vais revoir ça en profondeur.
Vive quand-même CloneZilla, hein !

Dernière modification par Lupa (02-04-2022 19:42:11)

raleur · 02-04-2022 20:32:07

Lupa a écrit :

Deux partitions ont le même point de montage.

Non, ça veut dire que les deux répertoires /mnt/DATA et /mnt/DONNEES appartiennent au même système de fichiers contenu dans /dev/sdb1 monté sur /mnt, et donc que rien n'est actuellement monté sur /mnt/DONNEES contrairement à ce qui est mentionné dans /etc/fstab montré au #13 (ni sur /mnt/DATA, mais c'est normal puisque rien n'est censé être monté sur ce répertoire dans /etc/fstab).

df

tout court affiche où est monté quoi.

Dernière modification par raleur (02-04-2022 20:47:46)

Debian-facile

#1 02-04-2022 10:32:56

[RESOLU]Owncloud : déplacement du dossier data

#2 02-04-2022 10:39:52

Re : [RESOLU]Owncloud : déplacement du dossier data

#3 02-04-2022 11:59:31

Re : [RESOLU]Owncloud : déplacement du dossier data

#4 02-04-2022 12:14:38

Re : [RESOLU]Owncloud : déplacement du dossier data

#5 02-04-2022 12:21:03

Re : [RESOLU]Owncloud : déplacement du dossier data

#6 02-04-2022 12:28:01

Re : [RESOLU]Owncloud : déplacement du dossier data

#7 02-04-2022 12:56:53

Re : [RESOLU]Owncloud : déplacement du dossier data

#8 02-04-2022 13:29:00

Re : [RESOLU]Owncloud : déplacement du dossier data

#9 02-04-2022 14:17:53

Re : [RESOLU]Owncloud : déplacement du dossier data

#10 02-04-2022 14:42:09

Re : [RESOLU]Owncloud : déplacement du dossier data

#11 02-04-2022 15:44:12

Re : [RESOLU]Owncloud : déplacement du dossier data

#12 02-04-2022 15:56:27

Re : [RESOLU]Owncloud : déplacement du dossier data

#13 02-04-2022 16:03:40

Re : [RESOLU]Owncloud : déplacement du dossier data

#14 02-04-2022 16:22:41

Re : [RESOLU]Owncloud : déplacement du dossier data

#15 02-04-2022 16:28:03

Re : [RESOLU]Owncloud : déplacement du dossier data

#16 02-04-2022 16:41:38

Re : [RESOLU]Owncloud : déplacement du dossier data

#17 02-04-2022 16:47:23

Re : [RESOLU]Owncloud : déplacement du dossier data

#18 02-04-2022 16:47:47

Re : [RESOLU]Owncloud : déplacement du dossier data

#19 02-04-2022 18:09:26

Re : [RESOLU]Owncloud : déplacement du dossier data

#20 02-04-2022 18:26:14

Re : [RESOLU]Owncloud : déplacement du dossier data

#21 02-04-2022 18:29:28

Re : [RESOLU]Owncloud : déplacement du dossier data

#22 02-04-2022 18:32:10

Re : [RESOLU]Owncloud : déplacement du dossier data

#23 02-04-2022 18:44:01

Re : [RESOLU]Owncloud : déplacement du dossier data

#24 02-04-2022 19:41:29

Re : [RESOLU]Owncloud : déplacement du dossier data

#25 02-04-2022 20:32:07

Re : [RESOLU]Owncloud : déplacement du dossier data

Pied de page des forums