[Tuto] ownCloud 7 / 8 sur un mutualisé OVH

Salut à toi, ami libriste ou simple curieux !

Vous l’attendiez tous (comme les précédents 😀 ), voilà le tutoriel d’installation d’ownCloud dans sa version 7 / 8 sur un hébergement mutualisé OVH.

Nouveautés ?

Oh que oui, il y a du nouveau ! Je vous la fait courte, j’ai pas tout testé, mais je vais commencer par un truc à mon sens essentiel : l’édition (avec coloration syntaxique s’il vous plait !) des fichier (La)TeX est enfin de la partie ! Je vais enfin pouvoir bosser gentiment sur mes rapports et diaporamas depuis n’importe où, sans me soucier d’avoir un éditeur sur la machine ou non, et je n’aurai plus qu’à compiler à ma maison…

Ensuite, de grosses améliorations ont été faites au niveau de la partie « partage ». Si je vous dit que je peux monter un dossier partager présent sur une autre instance directement dans la mienne et bosser comme si de rien n’était, et que mon instance se charge de faire remonter les modifs à l’hôte principal, vous me croyez ? Ben si ! 😉

Dans le même esprit, plein d’évolutions, les partages autorisés ou non par groupes et non plus seulement de façon globale, affichage du propriétaire du fichier partagé en regard de celui-ci, et… la disparition de ce *#$ »+& de dossier « Shared » (mais on peut le remettre… je ne le ferai pas 😀 ).

L’application Documents a été améliorée, mais ne supporte pour le moment que l’odt, comme la v6. L’ouverture de documents Word est aussi gérée, mais il faut installer libreoffice sur le serveur, ce que j’ai fait sur ma RPi, mais c’est chose impossible sur un mutualisé. Il est cependant possible d’indiquer à oC d’utiliser une instance de LibO présente sur un serveur externe <3

Oh, et la fenêtre principale « Fichiers » a changé, je vous laisse voir ça un peu plus bas !

Quoi d’autre… ah oui : une interface mobile, pour accéder « proprement » à votre cloud même si vous n’avez pas l’application ownCloud installée \o/

Et je trouve (ce n’est que mon ressenti) que la réactivité de l’ensemble est bien meilleure. Paradoxalement, l’archive d’installation a doublé de volume et dépasse les 100Mo… 😕

Y’a aussi tout un tas de trucs côté admin, mais je vous laisse un bout du plaisir de la découverte, quand même ! Dernier spoil : une interface pour configurer le SMTP d’envoi de mails, et les modèles de mails automatiques !

C’est pas merveilleux tout ça ?! 😛

 

Le guide

Rien de bien exceptionnel, c’est une reprise des guides précédents réadaptés au code de cette nouvelle version. On reprend, donc !

 

owncloudv7

 

 

Étape 1 : on récupère ownCloud, et on le met en ligne

Récupérez ownCloud 7 (7.0.1 au 7 août 2014), extrayez l’archive sur votre disque, et balancez le tout sur votre hébergement OVH (par FTP, donc), dans un beau sous-domaine tout neuf créé pour l’occasion via votre Manager.

N’allez pas encore sur la page web d’installation, on va bosser un peu avant 😉

 

Étape 2 : on trifouille le code

Pas de gros changement par rapport à la v6 pour les modifications à apporter. Tant mieux, j’ai pas à chercher cette fois 😉

Notez que le code ayant changé, vous pouvez en théorie installer ownCloud sans tout modifier. Mais si vous faites cela, vous n’aurez pas d’estimation de l’espace restant, par exemple. Mais ça tourne quand même, normalement, ce qui est en soi un progrès 😀

 

Modif 1 : .htaccess

Ce fichier est à la racine de votre dossier ownCloud. Si vous ne le voyez pas, pensez à afficher les fichiers cachés !

1
SetEnv PHP_VER 5_5

Ce fichier sera à re-modifier de la même façon après l’installation finale d’ownCloud 🙂

 

Modifs 2 : /lib/private/files/storage/local.php

Recherchez la ligne qui contient @disk_free_space (ligne 266 ici). Modifiez la ligne return \OC\Files\SPACE_UNKNOWN; (ligne 227 chez moi) pour y mettre quelque chose qui correspond vaguement à l’espace dont vous disposez. Dans mon cas, j’ai mis : return 25000000000; (environ 23Go).

On continue ?

 

Modif 3 : /config/config.php

Si jamais vous en avez plein le fondement des erreurs du genre « mééééh WebDAV fonctionne pas » alors qu’en fait si, éditer ce fichier et ajoutez :

1
'check_for_working_webdav' => false,

(à placer dans la liste, où vous voulez, mais pas en dehors quoi 😀 )

 

Étape 3 : installez ownCloud !

Rendez-vous sur la page d’installation de votre cloud personnel, donnez-lui un nom et un mot de passe pour le compte admin, configurez MySQL si vous le souhaitez (j’utilise SQLite, perso, par flemme).

 

C’est tout fini, et gardez en tête que la limite pour un fichier envoyé via l’interface Web est de 64Mio et aussi que l’appli Android du Play Store est payante, mais que F-Droid la compile gratuitement pour vous 😉

Hésitez pas s’il y a un souci, via les commentaires. Jetez avant un œil à ceux de l’article sur ownCloud v5 et v6, la réponse à vos questions y est sûrement déjà !

La bise à toutes et tous !

277 commentaires sur “[Tuto] ownCloud 7 / 8 sur un mutualisé OVH

  • 1 juillet 2014 à 11 h 49 min
    Permalink

    Merci pour ce nouveau tuto ! Quelqu’un a t-il tenté d’upgrader depuis la v6, ou on est dans l’obligation de tout écraser ?

    Réponse
    • 3 juillet 2014 à 10 h 21 min
      Permalink

      Personnellement, j’ai pas tenté, ma v6 me sert pour plusieurs projets, flemme de tout péter/remettre 😀

      Tu as essayé, toi ? 🙂

      Réponse
    • 25 avril 2015 à 17 h 08 min
      Permalink

      Bonsoir.

      Après plusieurs mois de résistance à la tentation, je viens d’essayer la mise à jour automatique depuis la version 6.0.4 vers la version 8.0.2 via l’interface d’admin Owncloud sur un hébergement mutualisé OVH.

      Ca commence par bien se passer puis on tombe sur un message d’erreur infernal que le logiciel invite à signaler à l’équipe de développement Owncloud. Plaisanterie à éviter donc. 🙁

      Je ne regrette pas d’avoir fait une sauvegarde auparavant par FTP et phpMyAdmin.

      J’essaie de refaire tomber en marche mais c’est moins instantané que ce que j’espérais. 😉 De toute manière, faut que ça le fasse, j’ai cinq personnes qui ont leurs données dessus, pas de rigolade !

      Pascal

      Réponse
  • 2 juillet 2014 à 10 h 22 min
    Permalink

    Install nickel, mais j’ai quand même dû modifier le fichier .htaccess.

    Merci pour le tuto !

    Réponse
    • 3 juillet 2014 à 10 h 22 min
      Permalink

      Ah, bah… je ne sais pas. Moi je n’ai pas eu à le faire 😕

      Content que ça te plaise/serve en tout cas 😉

      Réponse
  • 3 juillet 2014 à 6 h 57 min
    Permalink

    Bonjour,

    Après avoir suivis votre tuto pour l’installation d’owncloud sur un mutualisé ovh, je me confronte à un problème.

    dès que j’arrive à 2 Go de fichier téléversés, des erreurs apparaissent, internal server error, insufficient storage, et autre.

    Pourtant en verifiant, il reste au moins 15Go d’espace disponible sur le server.

    Merci d’avance pour vos éclairages.

    Réponse
    • 3 juillet 2014 à 6 h 59 min
      Permalink

      Nouveauté, depuis ce matin, il m’indique un message d’erreur lors e l’authentification.

      An exception occurred while executing ‘SELECT « oc_permissions ». »fileid », « permissions » FROM « oc_permissions » INNER JOIN « oc_filecache » ON « oc_permissions ». »fileid » = « oc_filecache ». »fileid » WHERE « oc_filecache ». »parent » = ? AND « oc_permissions ». »user » = ?’: SQLSTATE[HY000]: General error: 11 database disk image is malformed

      Réponse
      • 3 juillet 2014 à 10 h 10 min
        Permalink

        Hey,

        alors là… je ne connais pas (encore) assez ownCloud 7 pour te répondre autre chose que… Réinstalle ? Il y avait des soucis un peu dans ce genre avec la v6, trop de fichiers dans un sous-dossier par exemple, mais là, le second message indique lus une base de donnée endommagée. Tu utilises quoi, SQLite?

        Dans l’coup, je le rappelle, c’est une première version beta, donc il est normal qu’un certain nombre de bugs soient présents. C’est toute l’utilité de la chose ! N’hésite pas à les remonter à l’équipe de développement 🙂

        Et si tu as besoin de quelque chose de stable, direction la v6.0.4 😉

        Réponse
        • 3 juillet 2014 à 15 h 45 min
          Permalink

          il s’agit de la V6.0.4.
          Et pour la Bdd je ne sais pas du tout ce qu’elle utilise. Comment puis je savoir?

          Réponse
          • 7 juillet 2014 à 10 h 13 min
            Permalink

            Hey,

            dans ce cas, il aurait mieux valu demander sur la page de la v6 😉

            Bref. Pour connaître la BDD utilisée, ben… c’est celle que tu as définie à l’installation !
            Mais dans le fichier /owncloud/config/config.php tu as une ligne du type :

            1
            'dbtype' => 'sqlite3',

            (dans mon cas hein), où le dbtype indique ce que tu as choisi lors de l’installation de ton instance ownCloud.

  • 3 juillet 2014 à 20 h 04 min
    Permalink

    Bon install nickel, mais après upload de mes fichiers, j’ai un problème d’espace…
    J’ai bien vérifié la fonction

    1
    2
    3
    4
    5
    6
    7
    function ovh_free_space($path){
    $quota = shell_exec('quota | tail -n1');
    $quota_use = 1024*preg_replace('#^ +(\d+) +(\d+) [ \d]*#', '$1', $quota);
    $quota_total = 1024*preg_replace('#^ +(\d+) +(\d+) [ \d]*#', '$2', $quota);
    $quota_result = $quota_total - $quota_use;
    return $quota_result;
    }

    mais j’ai rien trouvé qui clochait…

    J’ai fini par reprendre la bidouille de GC (30 avril 2013, tuto OC 5), en remplaçant dans local.php la ligne

    1
    return @disk_free_space($this->datadir.$path);

    par

    1
    return 99999999999;

    (ce qui revient à renvoyer une valeur fixe).
    Peut-être pas très élégant, mais ça marche !

    Réponse
    • 3 juillet 2014 à 22 h 15 min
      Permalink

      je ne trouve pas cette ligne avec le return et meme dans le tuto
      peux tu me dire comment tu as fait ?

      Réponse
      • 4 juillet 2014 à 8 h 38 min
        Permalink

        C’est dans /lib/private/files/storage/local.php pour la function free_space (ligne 224 pour moi) :

        1
        2
        3
        4
        5
        6
        7
        8
        9
        10
        11
        12
        public function free_space($path) {
                       //$space = @disk_free_space($this->datadir . $path);
                       /*
                       * On appelle la fonction de l'API OVH
                       */
                       $space = ovh_free_space($this->datadir . $path);  
                       if ($space === false || is_null($space)) {
                            return \OC\Files\SPACE_UNKNOWN;
                       }
                       //return $space;
                       return 99999999999;
                  }
        Réponse
        • 5 juillet 2014 à 17 h 28 min
          Permalink

          bonjour
          Ah Ok
          On comprend la manip avec la copie ecran
          merci je vais essayer

          Réponse
          • 5 juillet 2014 à 21 h 51 min
            Permalink

            ca marche nikel !
            merci beaucoup 😉

        • 31 juillet 2014 à 8 h 05 min
          Permalink

          Merci pour la bidouille, je suis sauvé !
          Car la seul méthode d’abandon de soap n’avait pas résolu le problème ! comme je travaille alternativement sur 2 PC, cela me les re-synchronise parfaitement !
          Je me suis quand même limité à un peu moins !

          Réponse
    • 7 juillet 2014 à 10 h 15 min
      Permalink

      Salut,

      pas très élégant en effet… Je rencontre le même souci depuis quelques jours. Je me demande si OVH n’a pas fait une modif quelque part qui nous « empêche » d’utiliser les fonctions permettant de calculer l’espace libre. Je vais réessayer cet aprem’ avec la SoAPI, voir si c’est possible de revenir à cette méthode.

      Dans le coup, avec ta méthode, quelle info renvoie ownCloud en termes d’occupation de l’espace ? Il arrive à calculer un total réel, ou pas du tout ? 🙂

      Réponse
      • 7 juillet 2014 à 14 h 34 min
        Permalink

        Pour ce que j’en comprends, il renvoie une valeur arbitraire, ici 99999999999 octets (100Go).
        Il vaudrait beaucoup mieux avoir la vraie valeur…

        Réponse
        • 7 juillet 2014 à 17 h 37 min
          Permalink

          Oh, alors ça dépend de l’espace de chacun… Mon espace fait 25Go, je peux diviser par 4, mais bon. Boh, si ce qui est « à côté » de ownCloud est pas trop gros…

          Au pire, je vais mettre 22Go pour me laisser de la marge pour les autres sous-domaines 😉

          Réponse
      • 12 juillet 2014 à 17 h 36 min
        Permalink

        Bonjour,

        Merci pour ces tutos.

        Même problème pour le calcul de l’espace libre sous une version 6 (oui, oui, je sais c’est pas au bon endroit mais c’est pour confirmer qu’il ne s’agit pas d’un problème de version). Pas trouvé de solution…

        Merci pour ces tutos qui permettent à de « petits joueurs » comme moi de se lancer…

        Bonne continuation.

        Réponse
        • 14 juillet 2014 à 12 h 06 min
          Permalink

          Hey,

          pas de soucis pour la version, va ! 😉

          J’ai plutôt l’impression que c’est OVH qui a décidé de « brider » les fonctions que j’utilisais dans local_ovh.php…

          Dans l’coup et faute de mieux, autant fixer une valeur arbitraire d’espace total disponible et s’y tenir. Sûr que c’est moins classe/propre, mais ça a l’avantage de fonctionner…

          Merci pour le compliment, le but de ces tutos étant effectivement que tout un chacun puisse installer son système pour se passer de Dropbox & co. C’est un bon premier pas vers l’autonomie ! 🙂

          Réponse
  • 5 juillet 2014 à 11 h 33 min
    Permalink

    Héhé,
    Merci encore pour ce tutos (et pour les autres qui m’ont sauvé les miches plus d’une fois), je vais installer la version 7beta de ce pas 😀

    Réponse
    • 7 juillet 2014 à 10 h 18 min
      Permalink

      Salut !

      Ça me fait plaisir de te voir ici tiens 😉
      C’est normal de partager quelque chose quand on peut le faire, je trouve, et un « merci » est toujours agréable à lire/entendre !

      Dans l’coup, ownCloud 7 est déjà passée en RC1, j’ai fait la mise à jour aussi sec, j’ai pas remarqué grand chose de différent, mais j’ai pas fouiné non plus. Tu vas la réinstaller souvent, celle-là ? :mrgreen:

      A bientôt !

      Réponse
      • 7 juillet 2014 à 14 h 47 min
        Permalink

        Des précautions particulières pour la mise à jour vers RC1 ? (autre que pas de mise à jour automatique comme très clairement indiqué en début de tuto) ?

        Réponse
        • 7 juillet 2014 à 17 h 35 min
          Permalink

          Non, je n’ai rien fait de plus que refaire les modifications habituelles et tout rebalancer par FTP.

          Peut-être que la màj auto fonctionne à peu près, mais ça va quand même écraser les manipulations faites à la main. Si c’est pour les refaire par derrière… Bah, au pire ça fait gagner un peu de temps éventuellement ? Je n’ai pas essayé, honnêtement. 🙂

          Réponse
  • 13 juillet 2014 à 14 h 39 min
    Permalink

    Bonjour,

    Encore merci pour ces tutos que je suis depuis la version 5.

    Mais ici, je coince :

    J’ai installé OC 7 rc1 sur mon OVH mutualisé et lorsque je veux lancer OC 7 rc1 pour la première fois (en fait pour le paramétrer), j’obtiens l’erreur :

    1
    Fatal error: require(): Failed opening required 'version.php' (include_path='/home/monsite/www/owncloud/3rdparty/phpseclib/phpseclib/phpseclib:/home/monsite/www/owncloud/lib/private:/home/monsite/www/owncloud/config:/home/monsite/www/owncloud/3rdparty:/home/monsite/www/owncloud/apps:/home/monsite/www/owncloud/lib:.:/usr/local/php5.4/lib/php:/home/monsite/www/owncloud') in /home/monsite/www/owncloud/lib/private/util.php on line 282

    Je précise que j’ai suivi le tuto à la lettre y compris pour la version de php 5_4 dans .htaccess

    Merci de me donner une piste.

    Réponse
    • 14 juillet 2014 à 12 h 01 min
      Permalink

      Bonjour,
      essaie de renvoyer le fichier version.php manquant ? Ou de vérifier les droits sur ce fichier ? 🙂
      Et « au pire », vérifie qu’il a été transféré en utilisant le bon mode d’envoi (binaire plutôt que ASCII, de mémoire). Les clients récents détectent ça comme des grands en théorie, mais on sait jamais.

      Réponse
      • 15 juillet 2014 à 20 h 55 min
        Permalink

        Bonsoir,

        Alors après avoir testé différentes pistes, la réponse est :

        Le fichier version.php se trouve à la racine de OC 7 rc1 (genre /www/owncloud/version.php).

        Pour solutionner le problème, il suffit de le recopier dans le même répertoire que util.php à savoir /www/owncloud/lib/private/util.php.

        Pour info, créer un nouveau fichier « vide » nommé version.php dans le répertoire /www/owncloud/lib/private/ marche aussi.

        Merci d’avoir passé du temps à me répondre et encore chapeau pour ce tuto.

        Réponse
  • 23 juillet 2014 à 18 h 57 min
    Permalink

    Bonjour,

    La 7.0.0.8 stable étant sortie, j’ai tenté d’y passer depuis la 6.0.3.1 en procédant comme suit :
    – Upload de la 7 et application de ce tuto (très bien fait au passage) pour modifier les quelques fichiers indiqués
    – Migration « manuelle » telle qu’expliquée ici en 4 étapes :
    http://doc.owncloud.org/server/7.0/admin_manual/maintenance/migrating.html
    Ça semble simple, la cop1e du répertoire « data » étant l’étape la plus importante.
    Hormis le backup/restore de la base de donnée SQLite (impossible pour cause de « sqlite » ni « sqlite3 » absent sur un mutualisé OVH)
    – Enfin, pointage du lien www de l’ancien vers le nouveau répertoire.

    Mais voilà, ça ne marche pas du tout 🙁
    On tombe sur une page blanche (même après nettoyage des cookies).

    Ne pouvant pas redémarrer le serveur HTTP d’un mutualisé, j’aimerais savoir s’il y a un log quelque part pour avoir plus d’informations sur le pourquoi de la chose ?

    En creusant, j’ai constaté que la description de la base avait changée (fichier db_structure.xml à la racine).
    J’ai donc tenté de placer l’ancien db_structure.xml de la v6 à la place de celui de la v7 : rien de mieux dans mon problème
    Question : existe-t-il un outil accessible en ligne de commande (j’ai un accès ssh) pour migrer le schéma de la base de v6 à v7 ?
    Au pire, je ferais la migration sur mon Linux local et j’uploaderais le .db converti.

    Réponse
  • 29 juillet 2014 à 14 h 09 min
    Permalink

    Salut !

    J’avais un probleme en 6.x avec un client 1.5 et 1.3 de bad request 400 de csync que je n’ai jamais résolu … 🙁

    J’ai donc installé OC 7.0 stable sur un autre hebergement ( OVH quand meme) .. en suivant a la lettre le tuto ..

    Avec ma ‘vieille’ install de Xubuntu 14.04 a jour et OC client 1.6, même erreur…

    Avec une nouvelle install ( même PC, mais autre partition), avec OC client 1.5.6 ou 1.6.2 …=> même erreur …

    D’où donc que cela vient-il ???

    Réponse
  • 29 juillet 2014 à 14 h 28 min
    Permalink

    Une autre question me trote …
    Quelle différence y’a t-il entre utiliser le web install et balancer les 100Mo en FTP ..????

    Si php 5_4 n’est plus a mettre car, par defaut ..

    Réponse
  • 29 juillet 2014 à 19 h 41 min
    Permalink

    Bonjour,

    Je ne comprends pas, lorsque j’essaie de lancer l’installation j’obtiens une erreur « Cannot write into « apps » directory ». Pourtant, je suis bien allé changer les permissions du dossier apps pour les mettre en 777, donc bien writable.

    Est-ce que je manque quelque chose ??
    Merci d’avance : )

    Réponse
  • 31 juillet 2014 à 22 h 19 min
    Permalink

    Bonsoir.

    Merci pour le tuto.
    Cependant j’ai un petit problème, puisqu’il ne me détecte pas la taille disponible sur le mutualisé d’ovh…
    Pour info, owncloud n’est pas à la racine du serveur.

    Une idée ? Bon dev

    Réponse
  • 6 août 2014 à 12 h 17 min
    Permalink

    Salut,

    Merci pour la bidouille ! Ca marche bien avec le return de taille arbitraire 🙂

    Par contre il faudrait peut-être mettre dans l’article que la fonction de calcul de taille ne marche pas ? (je dis ça parce que j’ai mis un peu de temps a comprendre que la bidouille finale était dans les commentaires 🙂 )

    En tout cas merci, je vais pouvoir me passer de dropbox maintenant ^^

    Réponse
    • 7 août 2014 à 8 h 53 min
      Permalink

      Hey,

      ça fait un moment que je me dis que je dois le faire… tu as réussi à me motiver suffisamment pour que je m’active ce matin 😉

      C’est donc fait. Merci, et content que ce tuto te soit utile 🙂

      Réponse
      • 7 août 2014 à 12 h 20 min
        Permalink

        Merci Maxime,
        Difficile de se passer de owncloud (même si j’ai aussi dropbox à côté).

        Réponse
    • 7 août 2014 à 8 h 54 min
      Permalink

      Les modifier, ownCloud le fait. Les compiler… L’appli fait appel à un service externe je suppose ? Elle n’embarque pas TeXlive, si ?
      Si c’est fait à l’extérieur, personnellement ça m’ennuie :mrgreen:

      Réponse
      • 11 août 2014 à 10 h 12 min
        Permalink

        quand owncloud ne le faisait pas c’était bien pratique 😉
        il faut avoir texlive installer sur la machine

        Réponse
        • 18 août 2014 à 10 h 14 min
          Permalink

          Ah alors là c’est vachement cool ! Bon, c’est mort sur du mutualisé, mais sur le Raspberry Pi, ça devrait le faire \o/
          Je vais tester tout ça à l’occasion, merci 🙂

          Réponse
          • 20 août 2014 à 10 h 00 min
            Permalink

            oui, c’est pratique 😀
            par contre, il a pas l’ai de fonctionner sur owncloud 7 car ownCloud arrive a modifier les fichiers latex donc il se lance pas.
            faudait regarder un peu le code et réussir à le lancer quand meme avec les fichiers .tex

  • 7 août 2014 à 13 h 59 min
    Permalink

    Salut Maxime,

    Je suis tes tutos depuis un moment en mettant à jour régulièrement Owncloud sans le moindre soucis, mais depuis ce matin j’ai des erreurs avec la version 7. Une fois la MAJ faite (en respectant tes préconisations) j’ai ce message en me connectant
    Fatal error: Class ‘Sabre\DAV\URLUtil’ not found in /home/raptr/owncloud/lib/private/request.php on line 223
    A la ligne 223 de request.php j’ai cette instruction :

    1
    2
              // strip off the script name's dir and file name
              list($path, $name) = \Sabre\DAV\URLUtil::splitPath($scriptName);

    J’ai fait une réinstalle propre mais l’erreur apparaît toujours.
    Quelqu’un d’autre à déjà eu cette erreur ? Une idée de comment régler le problème ?

    Réponse
    • 7 août 2014 à 15 h 42 min
      Permalink

      Salut,

      jamais vu cette erreur…
      L’erreur ne provient a priori pas de la ligne indiquée. Au contraire, il te « dit » que cette ligne fait référence à la classe \Sabre\DAV\URLUtil, et que c’est cette classe qui n’a pas l’air d’exister.

      Dans le coup, vérifie que tu as bien tous les fichiers dans /home/raptr/owncloud/3rdparty/sabre/, dont lib/Sabre/DAV/URLUtil.php et/ou lib/Sabre/HTTP/URLUtil.php .
      M’est avis qu’il faut commencer par regarder de ce côté là.

      Sinon, on verra ailleurs… Bon courage \o/

      Réponse
      • 7 août 2014 à 22 h 00 min
        Permalink

        Merci Maxime, entre temps j’ai fais une deuxième réinstalle, maintenant ça passe 🙂

        Réponse
  • 10 août 2014 à 17 h 08 min
    Permalink

    Bonjour,
    Je suis actuellement je suis à la version 6.
    J’ai sauvegardé mes datas.
    Pour passer à la version 7, dois-je tout effacer sur mon FTP et suivre simplement le tuto pour installer la version 7?

    Réponse
    • 10 août 2014 à 19 h 06 min
      Permalink

      Une simple mise à jour automatique suffit. Après, juste à faire la petite manip’ pour l’espace disponible. Et ça devrait être tout bon !

      Réponse
      • 28 août 2014 à 8 h 40 min
        Permalink

        Bonjour,

        Merci pour les différents tutos qui jusqu’ici m’avait été utiles.
        Je déconseille la mise à jour automatique pour passer de la version 6 à la version 7, depuis que je l’ai faite, je reste sur un panneau d’accueil :

        « This ownCloud instance is currently being updated, which may take a while.
        Please reload this page after a short time to continue using ownCloud.
        Contact your system administrator if this message persists or appeared unexpectedly.
        Thank you for your patience. »

        Je n’ai pas encore réussi à m’en sortir, si quelqu’un à une idée je suis preneur, sinon, je continue de chercher…

        Réponse
        • 28 août 2014 à 8 h 42 min
          Permalink

          Hou, curieux, je l’ai déjà faire deux fois sans problème…

          Regarde dans ton config.php si le mode maintenance n’est pas activé, auquel cas tu peux essayer de le désactiver à la main. 🙂

          Réponse
          • 28 août 2014 à 9 h 17 min
            Permalink

            Encore une fois merci.
            Le site est de nouveau accessible, mais la mise à jour ne s’est pas completement terminée semble-t-il.
            Il me faut encore déplacer les datas qui ont été mis dans un répertoir temporaire…(et peut-être encore d’autres choses, mais je n’ai pas fait le tour du biniou…)

  • 18 août 2014 à 14 h 40 min
    Permalink

    J’ai un problème d’upload de fichier j’ai modifier le .htaccess ainsi que le php_ini rien a faire
    je peux pas uploader un fichier de plus de 30 mo j’ai fais le tour des forum est rien
    j’ai installer la dernière version (7) et je suis sur en serveur ovh Windows 2008 r2 avec IIS si
    quelqu’un peut m’aider

    merci d’avance

    Réponse
  • 19 août 2014 à 14 h 18 min
    Permalink

    Salut,
    cet article est destiné à celles et ceux qui installent ownCloud sur un hébergement mutualisé, avec les contraintes que ça impose… Dans ton cas, tu es sur un dédié, tu as donc toutes les possibilités de configuration.

    Je ne saurai que trop te recommander de passer de Windows Server/IIS à Linux/Apache (un LAMP quelconque, quoi), pour commencer.

    Ensuite, je n’ai aucune idée de comment est fichue la configuration PHP sous Windows/IIS. Je suppose que ça va à l’encontre de l’intuition, mais bref, « en temps normal » je te conseillerais de vérifier dans ton php.ini que la directive upload_max_filesize est bien à plus de 30Mo, et que max_execution_time est suffisamment élevé pour permettre l’envoi de plus de 30Mo (ce qui, à 1Mbps, prend déjà un certain temps). Ah et idem pour post_max_size, qui peut coincer sur l’envoi de données via POST si la taille est trop importante.

    J’espère que ça t’aide, sinon n’hésite pas, je peux chercher vite fait, mais je peux pas essayer, Windows est banni de ma maison ! 😉

    Réponse
  • 24 août 2014 à 21 h 55 min
    Permalink

    Merci pour ton boulot et ton bon esprit, c’est génial : ça marche très bien (v7.0.1.1) pour moi également, du moment que je laisse dans un sous-dossier « owncloud » au lieu de le mettre à la racine ou dans un sous-dossier différent (oui je refais bien tout à chaque essai). Pourtant j’ai cru comprendre que tu utilisais un sous-domaine dans ton cas.
    Cela me convient très bien ainsi (le sous-dossier owncloud et pas autre chose). Toutefois si t’as une idée, je prends.

    Réponse
  • 25 août 2014 à 20 h 36 min
    Permalink

    Bonjour,
    Je réf-poste ici bien que je sois toujours en version 6, mais là n’est pas le problème.
    J’ai une tablette en Win8 et un PC en win7.
    La synchro entre tablette et serveur OVH mutu se fait parfaitement.
    Par contre, le rapatriement des fichiers modifiés sur tablette vers le PC est bizarre : les fichiers semblent complets, mais leur nom est ésotérique : ils commencent par un point, se terminent par une combinaison de chiffres et lettres, entre deux, on retrouve le nom du fichier. J’ai essayé d’en ouvrir certains, ils semblent bien complets. Donc le nommage du fichier ne se termine pas correctement.
    J’ai désinstallé owncloud client du PC et réinstallé, c’est toujours pareil.
    Quelqu’un a-t-il une solution / remède simple au problème ?

    Réponse
  • 26 août 2014 à 1 h 42 min
    Permalink

    Salut,
    Rencontrez-vous encore ces fichus erreurs « 400 Bad Request » ??
    Suite à l’astuce que vous aviez donnée (return 2500000000;), ça a fonctionné une bonne semaine, et ensuite, rebelotte….
    Je suis passé de OC6 à 7 = même problème
    J’ai désactivé l’encryption et décrypté tous mes fichiers = même problème
    Une idée ?
    Merci d’avance.

    Réponse
    • 28 août 2014 à 8 h 55 min
      Permalink

      Salut,

      oui, je n’ai même que ça… à dire vrai, je ne comprends pas. J’ai installé le client Windows sur ma machine pro, et là, mystère : au boulot, ça passe sans soucis (via Renater), alors qu’à la maison, erreur 400 (via OVH). Alors que rien ne change quoi, même machine, même config, même instance ownCloud. Pis c’est quasi immédiat, là je suis au boulot, tout va bien, je me connecte au VPN de la maison, bam le client de synchro m’insulte.

      Si quelqu’un a une piste… J’ai bien posté sur Github mais pas de nouvelles pour le moment.

      Réponse
      • 22 septembre 2014 à 23 h 25 min
        Permalink

        Désolé pour le délai de réponse; je suis sur la route en ce moment !!
        Je viens de tester à nouveau, en me disant que peut-être OVH avait refait des modifs et que ça fonctionnerai à nouveau…et bien non, toujours pareil 🙁
        Du nouveau de ton côté ?
        Merci pour ce que tu fais en tout cas !

        Réponse
    • 1 octobre 2014 à 14 h 53 min
      Permalink

      Bonjour à tous,

      J’ai installé owncloud 7 sur OVH mutualisé.
      En clients :
      – à la maison, linux (LinuxMint 17)
      – au travail windows
      – GSM : android.

      Tout a fonctionné en suivant la procédure de Maxime; cela a duré deux semaines.
      Puis, le PC windows refuse la synchro.
      Message : « Erreur fatale CSync : mauvais paramètre. 400 Bad Request »

      mon PC Linux et mon GSM Android synchronisent toujours impeccablement.

      Le client windows a-t-il un problème ?

      Merci par avance pour toute suggestion.

      Chi

      Réponse
  • 27 août 2014 à 10 h 03 min
    Permalink

    j’ai tenté une mise à jour auto vers la version 7.01 sur ovh mutualisé j’ai maintenant une erreur
    [14] SQLSTATE[HY000] [14] unable to open database file

    une idée pour ma sauver

    merci d’avance

    Réponse
  • 2 septembre 2014 à 13 h 37 min
    Permalink

    Bonjour,

    novice en ce qui concerne owncloud et pas très fort en php 🙁

    Je suis sur OVH mutualisé, avec une base mysql.
    En lançant l’installation, j’ai le message
    Parse error: syntax error, unexpected ‘{‘ in /home/…./www/owncloud/index.php on line 24

    pourtant j’ai bien changé le .htaccess de la racine owncloud/ en ajoutant une ligne avant les autres

    1
    2
    3
    SetEnv PHP_VER 5_4
    <IfModule mod_fcgid.c>
    ...

    et également les autres conseils j’ai aussi changé

    1
    2
    3
    4
    5
    6
    7
    public function free_space($path) {
       $space = @disk_free_space($this->datadir . $path);
       if ($space === false || is_null($space)) {
       return 25000000000;
       }
       return $space;
    }

    Auparavant, j’ai installé owncloud sur mon easyphp local, sans aucun problème. également en mysql.
    Je n’avais changé aucun fichier php pour cette opération locale.

    merci pour toute suggestion

    Chi

    Réponse
    • 15 octobre 2014 à 23 h 30 min
      Permalink

      Salut,

      J’ai exactement le meme probleme que toi.
      As-tu trouvé la solution ?

      Merci pour ton aide.

      Eric

      Réponse
  • 16 septembre 2014 à 19 h 46 min
    Permalink

    Bonjour,

    Du nouveau concernant les applis qui ne fonctionnent pas ? Chez moi ça ne marche pas, j’ai toujours erreur 400 bad request… Une idée de comment résoudre ce satané problème ?

    Réponse
  • 17 septembre 2014 à 10 h 47 min
    Permalink

    J’ai rien dit finalement, en créant un nouveau dossier et en utilisant ce nouveau dossier, ça marche. 🙂

    Merci pour le tuto !

    Réponse
    • 17 septembre 2014 à 23 h 23 min
      Permalink

      Ah, super ! 🙂
      Pour les erreurs 400, j’en ai aussi, ça va, ça vient… Je sais pas pourquoi. 🙁

      Réponse
      • 3 octobre 2014 à 19 h 34 min
        Permalink

        J’en ai toujours lorsque je synchronise des dossiers qui sont dans des dossiers qui sont dans des dossiers.

        Par exemple, sous Windows, j’essaye de faire un backup de mes sauvegardes de jeux vidéo.
        Exemple :
        /Mes Documents/My Games/Dossier de jeu, Owncloud n’arrive pas à synchroniser…
        /Mes Documents/Dossier de jeu, il y arrive…

        Une idée ? :s

        Réponse
  • 19 septembre 2014 à 10 h 02 min
    Permalink

    Bonjour, j’ai un hébergement perso ovh et j’ai un soucis d’upload. La limite est bien a 64mo mais je n’arrive pas a envoyer des fichiers de plus de 30mo a peux pres! je vois bien l’activité reseau de mon ordi mais quand le fichier a fini de charger j’ai un message d’erreur du genre fichier introuvable. j’aimerai donc savoir si il y a une astuce pour limiter l’envoie, disons que je veux la limiter a 10mo. pour les gros fichier j’utiliserai le client sync ou le ftp.

    Réponse
    • 19 septembre 2014 à 10 h 30 min
      Permalink

      Hey,
      probablement un souci de temps d’exécution du script. Apache/PHP doit avoir un max_execution_time inférieur au temps qu’il te faut pour uploader ton fichier. C’est le souci de l’ADSL…

      De mémoire tu peux ajouter une ligne à ton fichier .htaccess (à la racine de ownCloud) :

      1
      php_value upload_max_filesize 10M

      pour dire à PHP de baisser la limite. Je ne suis pas certain de sa prise en compte sur un mutualisé, mais tu peux essayer ! 🙂

      Pour les applications, euh… la page de gestion mets bien quelques secondes à charger, oui, une dizaine chez moi je dirais, mais après c’est fluide. Tu as un souci supplémentaire avec ça ? 😕

      Réponse
      • 19 septembre 2014 à 10 h 42 min
        Permalink

        J’ai tester php_value upload_max_filesize 10M sans succès… Je me demande si il existe un autre hébergeur autre qu’ovh pour ce genre de cloud, si quelqu’un en connais un pas trop chère, je suis preneur.

        Réponse
  • 19 septembre 2014 à 10 h 03 min
    Permalink

    je rajoute aussi que quand je veux gérer les applications, c’est très très long a afficher la page…

    Réponse
  • 23 septembre 2014 à 20 h 34 min
    Permalink

    Bonjour
    Merci pour ces pages d’aide très utiles.
    J’ai installé owncloud 7.0.2 sur OVH en suivant les modifs. Et ça fonctionne ! Merci.
    Cependant j’ai ce message en rouge et en 1ere ligne dans Apps et je ne sais pas quoi faire :
    Security Warning
    You are accessing ownCloud via HTTP. We strongly suggest you configure your server to require using HTTPS instead.

    Puis-je faire qqchose ou est-ce OVH qui gère cette config de serveur ?

    Réponse
  • 24 septembre 2014 à 5 h 45 min
    Permalink

    J’utilise régulièrement owncloud sur mutu ovh, mais j’ai aussi au démarrage parfois quelques soucis car on me demande de confirmer l’acceptation du certificat de sécurité. Or, dans certains cas j’allume l’ordi sans y faire attention et le risque est ensuite de travailler sur un fichier obsolète (car mis à jour à partir d’une tablette).
    Comment peut-on résoudre ce point ? Qu’avez-vous fait ?

    Réponse
  • 1 octobre 2014 à 15 h 30 min
    Permalink

    Bonjour,

    Novice complet avec owncloud que j’ai découvert il y’a quelques semaines, je me suis décidé à suivre le guide pour l’installer sur mon serveur mutualisé ovh.
    J’ai un soucis à l’installation, j’ai le message suivant : « Cannot write into « apps » directory
    This can usually be fixed by giving the webserver write access to the apps directory or disabling the appstore in the config file. »

    J’ai vu qu’un autre utilisateur avait eu le même problème mais est resté sans réponse.
    J’ai pourtant bien modifié les autorisations du dossier ‘apps’ avec mon client ftp mais ça ne change rien.
    Des idées ?

    Réponse
  • 5 octobre 2014 à 16 h 44 min
    Permalink

    Bonjour, vous allez me dire que je suis à la masse mais je bloque quasi au début du tutoriel ^^

    J’explique: à la première on demande de « balancez le tout sur votre hébergement OVH (par FTP, donc), dans un beau sous-domaine tout neuf créé pour l’occasion via votre Manager »

    J’ai créé le sous-domaine, mais lorsque je me connecte en ftp, je peux me connecter seulement à mon nom de domaine. Ce n’est pourtant pas là que je dois mettre le tout non?

    Si je dois verser le tout dans le ftp de mon sous-domaine, il y a une procédure spéciale? ou bien je dois simplement attendre que ovh m’expédie le login et le mdp dédiés à mon sous-domaine?

    Ou bien, je peux créer un dossier « owncloud » dans le dossier /www qui se trouve à la racine du ftp de mon nom de domaine?

    Au plaisir de vous lire

    Réponse
    • 8 octobre 2014 à 13 h 10 min
      Permalink

      Alors…
      Lorsque tu crées un sous-domaine, tu lui indique un emplacement sur le serveur, un dossier qui se situe quelque part sur le FTP.

      Ainsi, ton domaine principal est dans /www/ .
      Si tu crées un sous-domaine type cloud.domaine.tld et que tu lui donnes comme emplacement /owncloud/, alors lorsque tu te connectes en FTP tu dois créer ce dossier owncloud et y téléverser les fichiers dont je parle.

      J’espère que c’est plus clair pour toi, sinon n’hésite surtout pas.
      À bientôt !

      Réponse
  • 8 octobre 2014 à 13 h 02 min
    Permalink

    Bonjour,

    Je ne sais pas si quelqu’un de ce forum peut m’aider ou me rediriger vers une piste.

    Le seul moyen de synchroniser ses adresses avec DavDroid en sécurité (https) est d’avoir un certificat SSL.
    Pour bénéficier du certificat d’OVH, on propose, dans une discussion du forum d’OVH (voir ici), d’utiliser une url du type « https://sslxxx.ovh.net/~LoginFTP/owncloud/ ».

    Pas de chance, DavDroid ne permet pas d’utiliser l’url « https://sslxxx.ovh.net/~LoginFTP/owncloud/ » , car il ne reconnaît pas le tilde « ~ ».
    Ce tilde, il me semble, est l’annonce d’un raccourci; donc ~loginFTP est en fait tout un ensemble de cheminement…

    J’ai demandé à OVH s’il était possible d’avoir le chemin du Home Ditrectory en clair… j’attends. —> https://sslXXX.ovh.net/homedirLoginFTP/

    Auriez-vous une idée pour synchroniser en htpps les carnets d’adresses de owncloud vers android ?

    merci

    Chi

    Réponse
    • 8 octobre 2014 à 13 h 33 min
      Permalink

      Salut,

      oui, DAVdroid ne fonctionne pas, et c’est pas faute d’avoir essayé… 2 options, en effet, le certificat auto-signé n’étant pas disponible sur un mutualisé (et c’est bien dommage…) : un chemin complet passant par sslxxx.ovh.net, ou… une modification du code de DAVdroid.

      Je n’ai pas beaucoup cherché pour le carnet d’adresses encore. Mais pour le calendrier, tu peux utiliser CalDAV Sync Adapter, qui fonctionne très bien.

      Je vais essayer de trouver un « truc » pour les contacts, mais si tu es plus rapide que moi, n’hésite pas à partager les infos ici 🙂

      Réponse
      • 10 octobre 2014 à 22 h 14 min
        Permalink

        Salut,
        Pour les contacts sur android j’utilise CarDav-Sync free et ça marche nickel. J’ai même pu désactiver les contacts grogueule, et n’utilise que ceux de mon owncloud.
        Pour le calandrier, j’utilise également CalDav Sync Adapter qui marche bien aussi.

        Réponse
    • 27 octobre 2014 à 15 h 54 min
      Permalink

      Commentaire à mon commentaire

      Après DavDroid, j’ai essayé d’installer acal, mon GSM le refuse ! sans explication.

      Puis, j’ai installé CardDAV-Sync 0.4.5 free beta (http://dmfs.org/carddav/?getit) : c’est ok pour le SSL.
      Cependant, les catégories ne se synchronisent pas ! Elles devraient être converties en groupes. Ce groupes sont effectivement créés dans le GSM, mais aucun contact n’est attaché à aucun groupe.

      Je cherche toujours donc.

      Réponse
  • 14 octobre 2014 à 22 h 20 min
    Permalink

    Même problème que MD et Fab : cannot write into « apps » directory. Est-ce que vous avez trouvé la solution à ce problème? Merci,

    Réponse
  • 15 octobre 2014 à 15 h 57 min
    Permalink

    Alors pour les intéressés (mais bon il doit pas y’en avoir beaucoup 😉 ) j’ai résolu mon problème de « cannot write to apps directory »
    J’ai mené mon enquête, et en fouinant un peu sur le forum officiel d’owncloud on tombe sur un sujet qui parle de problème de chemin qui ne serait pas le bon dans le config.php.
    Après avoir tenté plusieurs modif sans résultat probant, j’ai fini par désactiver l’appstore comme il est préconisé sur la page qui indique le fameux message d’erreur (éditer le config.php -> appstoreenabled => false)
    Je recharge la page et là je tombe bien sur la page de config, mais un peu frustré quand même je me dis que j’aimerais bien faire fonctionner l’appstore, et à cet instant précis je vois donc sur la page d’accueil le lien « storage & database » sur lequel je clique, et dans le champ ‘data folder’ qui apparait je lis : /home/toto/www/owncloud/data (remplacez toto par votre nom de domaine sans le .truc)

    Dans le config.php par défaut on trouve la ligne suivante :
    ‘path’ => ‘/var/www/owncloud/apps’,

    que je me suis empressé de remplacer par :
    ‘path’ => ‘/home/toto/www/owncloud/apps’,

    j’ai remis le appstore sur true, et ça fonctionne.

    Réponse
  • 16 octobre 2014 à 11 h 14 min
    Permalink

    Help please ! :p

    Le logiciel ownCloud sous Windows et sous Linux n’arrive pas à uploader des sous-dossiers. J’ai l’impression qu’il n’arrive pas à créer ces sous-dossiers…

    Une idée ? Changer les droits d’accès aux fichiers ?

    Réponse
  • 22 octobre 2014 à 10 h 03 min
    Permalink

    Bonjour, quelqu’un connais un hébergeur compatible et sans prise de tête (modifier x fichier ect..) pour owncloud?

    Merci

    Réponse
    • 25 octobre 2014 à 10 h 24 min
      Permalink

      Salut,

      non, je n’en connais pas, du moins pas sans auto-héberger ton cloud ou passer par un VPS ou un dédié. Si quelqu’un d’autre a des idées, je suis preneur 🙂

      Réponse
  • 3 novembre 2014 à 10 h 38 min
    Permalink

    Bonjour,
    J’ai installé Owncloud sur un mutualisé OVH en suivant la procédure décrite dans ce magnifique tutoriel.
    Tout semble aller au niveau de l’installation. J’ai d’ailleurs pu me connecter avec Android.

    Mais aucune synchronisation ne se fait avec le logiciel Owncloud pour Windows 7…
    J’obtiens le message d’erreur suivant :

    J’ai vu dans les commentaires plusieurs bugs similaires mais aucune solution.

    Merci d’avance,
    Laurent

    Réponse
  • 3 novembre 2014 à 10 h 43 min
    Permalink

    J’ai pas bien géré la balise quote…
    Voici le message d’erreur :

    CSync fatal parameter error. 400 Bad Request

    Merci pour votre aide,
    Laurent

    Réponse
  • 3 novembre 2014 à 16 h 17 min
    Permalink

    Bonjour,
    bon apparement il ne faut pas prendre OVH mutualisé pour faire du Ownclound…
    Mettons nous a la recherche d’un herbergeur qui est compatible et sans modif a faire..

    A bientot

    Réponse
    • 12 novembre 2014 à 16 h 01 min
      Permalink

      Pourquoi un retour si négatif ? Ça fonctionne, mais effectivement, si 2-3 modifs sont si rebutantes…

      Un hébergeur avec ce débit et à ce prix, bon courage, quand même. La meilleure solution reste l’auto-hébergement, comme bien souvent, mais ça ne convient pas à tout le monde.

      Personnellement, à part cette fameuse erreur CSync 400 du client plus ou moins aléatoire, j’ai aucun souci et je n’ai franchement pas à me plaindre.

      Réponse
  • 4 novembre 2014 à 19 h 29 min
    Permalink

    J’ai le même problème que vous autres avec le client Windows « CSync … Bad Request ». Dommage 🙁

    Je n’arrive pas à ajouter en tant que lecteur réseau dans Windows via Webdav mais l’url Webdav fonctionne dans un navigateur.

    Le client android fonctionne.

    C’était pourtant assez prometteur et tout le reste fonctionne. Allez, espérons que ça (re)marche un jour…

    Réponse
  • 5 novembre 2014 à 13 h 55 min
    Permalink

    Bonjour
    Merci pour ce tuto sur lequel je suis tombé alors que j’avais déjà installé owncloud (7.0.2) sur mon mutu ovh (offre perso).
    Pour l’instant je commence à faire qques tests. Je compte m’en servir qu’en backup (pas de synchro)

    J’ai installé par la procédure automatique sans problème, j’ai pu accéder depuis un iphone.
    je me pose qques questions cependant.
    1- A partir de quel volume vaut-il mieux utiliser MySQL ?
    2- j’ai testé les applis tierces mais quand je veux en activer certaines j’ai ce message
    « L’application ne peut être installée car elle contient du code non-autorisé ». Est ce dû à la config OVH ou à l’appli elle-même ?
    3- Peut-on mettre le répertoire /data en dehors de l’arborescence www ?
    4-Même si ça sort un peu du cadre de ce tuto, je tente le coup 😉
    Pour l’instant, mon cloud est accessible via http://www.mondomaine.fr/owncloud. Est-il possible qu’il soit accessible comme ceci http://owncloud.mondomaine.fr/ ?

    Pour ceux qui n’auraient pas vu, l’espace alloué pour l’offre perso est passé de 25 à 100Go ce qui est d’autant plus intéresssant pour installer un owncloud !

    Merci d’avance

    Réponse
    • 5 novembre 2014 à 21 h 20 min
      Permalink

      réponse à la question 3: oui. On peut même déplacer le répertoire après l’installation en modifiant la valeur de datadirectory dans le fichier owncloud\config\config.php

      Réponse
    • 12 novembre 2014 à 15 h 38 min
      Permalink

      Bonjour,

      1*/ Alors là, c’est *la* colle. Je suppose que ça dépend en partie de la machine qui héberge… Je laisserai d’autres plus au fait que moi répondre 😉

      2*/ À moins que tu aies oublié de désactiver le pare-feu applicatif dans ton manager OVH (et je ne crois pas qu’il génère ce genre de messages), c’est bien ownCloud qui filtre. Il me semble que ça avait été rapporté pour l’appli « News », dont une version « spécifique ownCloud 7 » était sortie pour être utilisable à nouveau.

      3*/ Tout à fait, et comme tu l’as dit toi-même, il y a juste une modif à faire dans config.php .

      4*/ Bien sûr, je te conseille même de faire comme ça 😉
      Tu crées un dossier « owncloud » par exemple dans ton arborescence FTP, à la racine (même niveau que www), et tu y envoies les fichiers d’installation de ownCloud. Ensuite, tu crées un sous-domaine dans ton manager qui au lieu de pointer sur /www va pointer sur /owncloud, puis une fois la propagation DNS effective, tu pourras accéder à sousdomaine.domaineprincipal.tld et suivre les instructions d’installation de ownCloud.

      Voilà voilà, si tu as d’autres questions, n’hésite pas ! 😀

      Réponse
  • 11 novembre 2014 à 15 h 24 min
    Permalink

    Bonjour Maxime,
    J’avais suivi avec attention votre tutoriel pour la version 6, et j’ai suivi celui plus haut pour la version 7 car je viens d’installer OC sur un autre serveur. Merci pour ce partage !
    Mais… Il y a souvent un « mais »…
    Mon installation semble fonctionné correctement mais je n’arrive pas du tout à faire les synchro avec mon iPhone ou mon Mac via les « DAV » (calDAV, cardDAV ou webDAV) alors que cela fonctionne très bien avec ma « vieille » installation (OC6) sur un autre serveur ! Auriez-vous, Maxime ou les autres, une idée pour m’aider ? J’ai explicité mon problème sur ce post chez owncloud.fr
    Merci d’avance !

    Réponse
    • 12 novembre 2014 à 15 h 46 min
      Permalink

      Salut,

      alors là… je ne sais pas trop quoi te dire. Les versions précédentes avaient déjà des « spécificités » pour fonctionner avec les outils Apple.
      Personnellement, je ne supporte pas la marque (éthique, business model, tout un tas de raisons) et je n’ai donc rien à portée qui me permette de tester sur mon cloud.

      Je ne pense pas que ce soit lié au certificat SSL, puisque ça fonctionne avec OC6.

      Tu peux jeter un oeil, une simple recherche Google te montre qu’avec Mac OS et iOS, c’est un peu la foire à la saucisse (végétale, on se refait pas) concernant la configuration.
      Un topic en particulier à lire, je pense.

      Attention cependant, le souci n’est pas une « incompatibilité » de SabreDAV, qui a implémenté correctement les protocoles *DAV… C’est à Apple d’apprendre à respecter les standards, pour changer (et puis bon, si on s’embête à les faire, ces standards, c’est quand même pour s’en servir, intéropérabilité, tout ça… ah, on me souffle dans l’oreillette que comme c’est « cassé » ça pousse les gens à rester avec les services de la pomme 😀 ).
      Non, plus sérieusement, je penche plus pour un « bricolage » de la conf iOS/OSX, SabreDAV fonctionnant très bien de son côté (la preuve, via navigateur ou autre soft tu accèdes bien à tes données 🙂 ).

      Tiens-moi au courant ! Et bon courage :mrgreen:

      Réponse
      • 17 novembre 2014 à 21 h 59 min
        Permalink

        Bonsoir,
        Merci Maxime pour ta réponse. J’ai depuis avancé un peu : j’ai profité de la sortie d’OC v.7.0.3 pour tout recommencer : cela a aboutit à… la même chose… Malheureusement !
        En fait, cela me dit que je n’ai pas les bons identifiants lorsque j’essaye de me connecter soit via le client « lourd » (application native) soit à la page …
        Alors que je rentre bien les bons identifiants, preuve en est que lorsque je m’identifie directement sur l’interface classique cela fonctionne bien.
        Ce qui est encore plus « perturbant », c’est que cela fonctionne bien (notamment le client lourd) sur mon autre installation (l’ancienne, OC en v.6). D’où ma conclusion qu’il s’agit d’un problème d’authentification dans la v.7…
        Pour valider cette hypothèse, il faudrait que je tente d’installer la v.6 sur ce serveur en fait… Mais c’est encore reprendre ce temps là !
        Bref, si quelqu’un a une autre idée (meilleure ;-), je suis preneur !
        Merci d’avance,
        Hugues

        Réponse
        • 20 novembre 2014 à 8 h 51 min
          Permalink

          Bonjour Hugues,

          Je rencontre le même problème que toi depuis le passage en 7.0.3 (sur hébergement OVH). Le problème est présent aussi bien pour Iphone Ipad que pour Android (avec appli Caldav) !
          Sur Android/Caldav il me dit que l’url est invalide alors que je fais un copié/collé du lien et que si je teste le lien sur le navigateur web il fonctionne très bien.
          Donc, comme toi, je pense qu’il s’agit d’un problème lié à la version OwnCloud (même si pour moi je n’avais pas constaté de problème dans la 7.0.2).
          J’espère qu’on va trouver la solution car c’est très pénalisant 🙁

          Réponse
          • 22 novembre 2014 à 10 h 37 min
            Permalink

            J’ai peut être trouvé une partie de la réponse sur le forum.
            J’ai modifié le fichier config/config.php en ajoutant une ligne :
            array (
            0 => ‘******.com’,
            1 => ‘******.com:80’,
            ),
            Ça semble fonctionner pour la synchro Caldav (Android) par contre pas pour la synchro Ipad & Iphone.

          • 22 novembre 2014 à 15 h 26 min
            Permalink

            Bonjour Guillaume,

            Merci pour ce partage. J’ai effectivement trouvé aussi ces infos par .
            Testé un peu pour ma configuration mais sans succès comme tu dis pour la synchro avec les ibidules… Je suis preneur si tu as d’autres pistes !
            J’ai demandé à OVH de regarder également, ils ne m’ont pas encore répondu.

            Bonne journée !

          • 23 novembre 2014 à 15 h 47 min
            Permalink

            Bonjour,
            C’est réglé pour ma part après avoir encore bien tripatouiller diverses choses…
            La solution était dans ma configuration de mon ancien serveur, au niveau du fichier htaccess, que j’ai donc adapté pour l’occasion :

            1
            2
            3
            4
            5
            6
            7
            8
            9
            10
            11
            12
            13
            14
            15
            16
            17
            18
            19
            20
            21
            22
            23
            24
            25
            26
            27
            28
            29
            30
            31
            32
            SetEnv PHP_VER 5_4

            <IfModule mod_fcgid.c>
            <IfModule mod_setenvif.c>
            <IfModule mod_headers.c>
            SetEnvIfNoCase ^Authorization$ "(.+)" XAUTHORIZATION=$1
            RequestHeader set XAuthorization %{XAUTHORIZATION}e env=XAUTHORIZATION
            </IfModule>
            </IfModule>
            </IfModule>

            # <IfModule mod_php5.c>
            # php_value upload_max_filesize 512M
            # php_value post_max_size 512M
            # php_value memory_limit 512M
            # php_value mbstring.func_overload 0
            # <IfModule env_module>
            #   SetEnv htaccessWorking true
            # </IfModule>
            # </IfModule>
            <IfModule mod_rewrite.c>
            RewriteEngine on
            RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
            RewriteRule ^.well-known/host-meta /public.php?service=host-meta [QSA,L]
            RewriteRule ^.well-known/carddav /remote.php/carddav/ [R]
            RewriteRule ^.well-known/caldav /remote.php/caldav/ [R]
            # RewriteRule ^apps/([^/]*)/(.*\.(css|php))$ index.php?app=$1&getfile=$2 [QSA,L]
            RewriteRule ^remote/(.*) remote.php [QSA,L]
            </IfModule>

            ErrorDocument 403 /core/templates/403.php
            ErrorDocument 404 /core/templates/404.php

            Avec cela, tout fonctionne au niveau de la synchronisation entre le serveur OwnCloud, le mac (applications calendrier et contacts) et l’iPhone.
            Ce post peut t’être utile Guillaume…

            A+,
            Hugues

          • 23 novembre 2014 à 19 h 30 min
            Permalink

            Merci Hugues 🙂

  • 13 novembre 2014 à 0 h 07 min
    Permalink

    Bonjour tout le monde. J’suis un newbie en info, je viens d’installer owncloud 7 sur OVH mutualisé. J’ai suivi la procédure à la lettre mais pas moyen d’uploader des fichiers de plus de 20/30 mo. A chaque fois le message d’erreur est le suivant : « impossible de définir le dossier pour l’upload, charger. » Est-ce que quelqu’un peut me donner un coup de main? Merci d’avance!

    Réponse
    • 13 novembre 2014 à 10 h 38 min
      Permalink

      Bonjour,

      quand tu dis que tu essaies de téléverser des fichiers de 20-30Mo, est-ce que c’est via l’interface web ou par le biais du client de synchro de bureau ?

      Par l’interface web, il est fort probable que ton débit soit insuffisant, et qu’arrivé à 20-30Mo tu atteignes le max_execution_time défini par OVH dans la configuration de PHP. Et là, sur un mutualisé, il n’y a rien à faire : on n’a pas accès à cette configuration.

      Par le client tu ne devrais a priori pas rencontrer ce souci. Et dans le pire des cas : si tu as un fichier trop imposant, transfère-le par FTP ! 😉

      Bon courage 🙂

      Réponse
      • 15 novembre 2014 à 15 h 52 min
        Permalink

        Merci pour tes réponses! (Je parlais bien de l’interface web effectivement.)
        A bientôt,

        Réponse
  • 26 novembre 2014 à 13 h 33 min
    Permalink

    Bonjour,

    Je viens de faire une nouvelle install d’owncloud pour une assoce, toujours hébergé chez OVH (mutualisé).
    Pas de souci particulier, sauf que j’ai dû ajouter la ligne :

    1
    SetEnv MAGIC_QUOTES 0

    dans le fichier .htaccess pour désactiver les magic quotes.

    François

    Réponse
  • 15 décembre 2014 à 11 h 33 min
    Permalink

    La version 7.0.4 est de sortie, est ce qu’il y a toujours des problèmes avec ou non?

    Réponse
    • 24 décembre 2014 à 11 h 50 min
      Permalink

      Je n’ai pas remarqué de changements majeurs… Pas du côté des erreurs de synchro qui doivent pourtant bien avoir une origine identifiable !

      Identique à « avant » pour moi : à la maison ça foire, au boulot ça passe… C’est à n’y rien comprendre ! 😕

      Réponse
  • 25 décembre 2014 à 22 h 58 min
    Permalink

    Bonjour,

    Comment gérez vous l’accès en SSL de votre sous-domaine pour Owncloud avec OVH mutualisé ? J’ai beau cherché il semble qu’il ne soit pas possible (gratuitement) d’atteindre un sous-domaine en SSL.
    Soit j’installe Owncloud dans www/owncloud et je peux utiliser SSL, soit c’est un sous-domaine (avant www) et là je dois faire sans.

    Est-ce que cela veut dire que vous vous passez de SSL ?

    Merci !

    Réponse
    • 25 décembre 2014 à 23 h 33 min
      Permalink

      Bonjour,

      oh que non, je ne me passe pas de SSL… 😉
      J’accède quand même au sous-domaine, sans aucun problème, à part que le certificat mutualisé ne correspond pas au nom de domaine quoi (sslXX.ovh.net), donc avertissement et voilà…

      Mais c’est mieux que rien du tout !

      Réponse
  • 1 janvier 2015 à 11 h 00 min
    Permalink

    Bonjour à tous et bonne année!
    Je viens d’installer la version 7.0.4 sur un OVH mutualisé. J’ai eu des soucis avec un pb de droit sur le dossier apps, mais j’ai vu plus haut qu’il fallait modifier le fichier de config ça c’est ok.
    Du coup j’ai pu créer mon utilisateur admin et configurer ma base. LE pb maintenant je tourne en boucle sur
    « ownCloud sera mis à jour vers la version 7.0.4.
    Veuillez vous assurer qu’une copie de sauvegarde de la base de données, du dossier de configuration et du dossier de données a été réalisée avant le commencement de la procédure.
    Démarrer la mise à jour »

    Je clic sur démarrer et la, j’ai la page

    « Updating ownCloud to version 7.0.4, this may take a while.
    Please reload the page. »

    Rien ne se passe, je recharge la page et je tombe sur la page précédente!!!

    Réponse
    • 27 janvier 2015 à 14 h 33 min
      Permalink

      Salut,
      tu t’en es sorti ? Désactiver le mode maintenance à la main ne suffit pas ? 😕

      J’attends ton retour 🙂
      Et une très bonne année à toi aussi !

      Réponse
  • 19 janvier 2015 à 17 h 16 min
    Permalink

    Hello !
    J’ai passé toute la matinée à essayer d’installer OC, ce qui a l’air de se faire bien vu que j’arrive à y accéder depuis navigateur sans soucis mais au moment de configurer le logiciel après avoir rentré l’adresse https, login et password, validé l’avertissement SSL je me retrouve avec cette erreur :

    Impossible de se connecter de manière sécurisée :
    Operation canceled
    Voulez-vous vous connecter de manière non sécurisée (sans chiffrement) ?

    Que je valide ou pas ça ne change rien du tout…
    Les seules modifs que j’ai fait lors dans les paramètres sont dans sécurité j’ai forcé le https mais même en décochant ça ne change rien.

    Une idée d’où ça pourrait venir ?

    Réponse
    • 27 janvier 2015 à 14 h 37 min
      Permalink

      Salut,

      le client que tu configures, c’est sous quel système d’exploitation stp ? 🙂
      C’est étrange, tu sais si le client Android se connecte bien ?

      L’adresse à entrer est celle du domaine, pas celle donnée par le partage WebDAV.

      Il « suffit » de forcer https et de désactiver la vérification, normalement, c’est bizarre…
      J’attends tes retours alors ! 🙂

      Réponse
  • 30 janvier 2015 à 16 h 15 min
    Permalink

    Bonjour à tous, bonjour Maxime,

    Je vais faire bref si possible, je suis actuellement stagiaire dans une organisation et la responsable com’ me demande de trouver des solutions pour partager fichiers, contacts et autres données entre les 2 bureaux (Un en Espagne, le 2e en France).

    C’est alors que je suis tombé sur OC. Il convient parfaitement à ce qu’on recherche. Le soucis c’est que c’est moi qui dois l’installer tout seul comme un grand sur le serveur de chez notre hébergeur ( FullSave.com ) j’ai quelques bases en dev web, mais traficoter dans le serveur de l’orga et y foutre le merdier, c’est plutôt moyen à expliquer à mes supérieurs. Je comprends une partie de ton tuto mais je sais pas si j’y arriverais sans finir avec des cheveux en moins. BREF.

    Je me demandais si l’utilitaire Web Installer proposé par OwnCloud était efficace pour installer OC sur un serveur mutualisé sans forcement mettre les mains dans le cambouis.
    Si c’est pas le cas j’irai sortir mon bleu de travail pour l’installer comme un homme.

    Merci d’avance pour vos réponses.

    PS: Merci pour ce tuto

    Réponse
    • 3 février 2015 à 22 h 23 min
      Permalink

      Salut à toi, ami stagiaire !
      (ouais, je l’étais aussi jusqu’à il y a quelques jours… Je compatis 😉 )

      En effet, ownCloud répond à ton besoin même si ce n’est pas la seule et unique solution.
      Si tu crées un sous-domaine pour ton installation, ou que tu « ranges » oC dans un dossier qui lui est propre, tu peux lancer le script d’installation automatique. Au pire, ça fonctionne pas parce que les pré-requis ne sont pas remplis, au mieux tout marche « out-of-the-box ».
      Le cas intermédiaire étant que l’installateur fonctionne, mais que des restrictions d’usage sur le serveur posent souci.

      Dans le coup, est-ce qu’il s’agit d’un dédié (là, c’est no limit, au pire ça demande un poil de config de la part de l’adminsys) ou d’un mutualisé (et là, c’est un peu pile ou face, quoi qu’avec la chance que j’ai là je peux faire tomber la pièce sur la tranche je pense 😀 ) ?

      Si tu as besoin d’un coup de main, de conseils, d’être guidé… Hésite pas hein, un mail, ou via le formulaire de contact, et on peut faire ça ensemble.

      À bientôt !

      Maxime

      Réponse
      • 10 février 2015 à 12 h 37 min
        Permalink

        Merci Maxime pour ta réponse.

        Finalement mon responsable à préféré se tourner vers une solution online payante pour des questions de maintenance. Personne dans le service n’est capable de gérer la maintenance et les mises à jour de OC ni d’aucune autre solution. Il n’y a aucun adminsys ni reponsable informatique. Pour tout ce qui touche au web et à l’informatique en général ils passent par des prestataires plus ou moins compétant.

        Ils ne veulent pas se prendre la tête avec ça et préfèrent mettre la main au portefeuille pour n’avoir rien à gérer et être tranquille. D’un coté je peux les comprendre, surtout si il n’y connaissent rien.

        En tout cas je te remercie pour ta réponse.

        Bonne continuation à toi

        Kevin

        Réponse
  • 4 février 2015 à 19 h 01 min
    Permalink

    J’ai un soucis avec le client linux (debian) qui me refuse toute connexion en me disant faisant une error 1060 SSL handshake failed: secure connection truncated, et je ne comprends pas pourquoi 🙁

    je donne bien comme adresse de connexion le https://sslX.ovh.net/~X/sousdossier

    le client n’arrive jamais a se connecter je ne comprends pas trop pourquoi.

    Y-a-t-il d’autres pesonnes a l’utiliser avec un client desktop ? (et avec succès?)

    Merci et bonne journée!

    Réponse
  • 10 février 2015 à 11 h 34 min
    Permalink

    Owncloud 8 est sortie! Espérons que celui ci fonctionnera mieux avec ovh…

    Réponse
  • 28 février 2015 à 13 h 42 min
    Permalink

    Bonjour
    quelqu’un a-t-il déjà essayé le 8 sur OVH ?

    Réponse
  • 28 février 2015 à 15 h 29 min
    Permalink

    Bonjour
    Je suis actuellement en version 7 (mutu ovh) et je voulais savoir s’il y avait des précautions particulières à prendre avant de passer en version 8.

    Merci d’avance

    Christian

    Réponse
    • 28 février 2015 à 17 h 59 min
      Permalink

      Oui, notamment au niveau de la partie agenda qui n’est pas compatible entre la version 7 et 8.
      Je te conseille de tout sauvegarder avant la mise à jour (agenda et contacts).
      Comme j’avais des soucis avec la MAJ. J’ai fait une réinstallation complète (heureusement j’avais les sauvegardes) et j’en ai profité pour mettre le dossier data en dehors du dossier ownCloud ce qui je pense est mieux pour de futures mises à jour.

      Réponse
    • 5 mars 2015 à 12 h 12 min
      Permalink

      Pas plus de précautions qu’auparavant. J’ai dû, comme Guillaume, réimporter mes données, mais rien de bien méchant, c’est juste long…

      Tout le reste fonctionne à la perfection cela dit, une fois l’espace disque « disponible » entré en dur dans local.php, comme pour la v7.

      Bon courage 🙂

      Réponse
      • 5 mars 2015 à 13 h 51 min
        Permalink

        Merci pour ces informations.
        Je vais attendre la sortie de la 8.1 avant de ma lancer.

        Christian

        Réponse
        • 6 mars 2015 à 10 h 18 min
          Permalink

          Tu attends la 8.0.1 (première version de maintenance de la v8) ou réellement la 8.1 ?
          C’est quelque chose comme mai et avril, respectivement, pour la sortie.

          Tu peux aussi installer le « daily build » de la v8 hein, qui intègre déjà de nombreux correctifs.

          Réponse
          • 6 mars 2015 à 10 h 30 min
            Permalink

            J’attends la 8.01. Qui doit sortir dans les prochains jours.
            Et surtout j’attends d’avoir du temps pour faire le changement tranquillement.

            Christian

  • 6 mars 2015 à 10 h 37 min
    Permalink

    La version 8.1 corrige les bugs sur OVH?

    Réponse
    • 6 mars 2015 à 10 h 38 min
      Permalink

      Quels bugs ? À l’utilisation, je n’en ai pas moi, sauf l’erreur CSync 400 depuis certaines connexions ADSL (pas toutes…).

      Réponse
  • 5 avril 2015 à 8 h 28 min
    Permalink

    Bonjour,

    Lors de l’installation, j’ai une erreur :

    Fatal error: require(): Failed opening required ‘version.php’ (include_path=’/home/mon-site/cloud-mon-site/3rdparty/phpseclib/phpseclib/phpseclib:/home/mon-site/cloud-mon-site/3rdparty/pear/pear_exception:/home/mon-site/cloud-mon-site/3rdparty/pear/archive_tar:/home/mon-site/cloud-mon-site/lib/private:/home/mon-site/cloud-mon-site/config:/home/mon-site/cloud-mon-site/3rdparty:/home/mon-site/cloud-mon-site/apps:/home/mon-site/cloud-mon-site/lib:.:/usr/local/php5.4/lib/php:/home/mon-site/cloud-mon-site’) in /home/mon-site/cloud-mon-site/lib/private/util.php on line 320

    Une idée ?

    Réponse
    • 7 avril 2015 à 7 h 04 min
      Permalink

      Bonjour,

      est-ce que tous tes fichiers ont bien été transférés ? Parce que là, a priori, il cherche un fichier ‘version.php’ qu’il ne trouve pas. La référence y est faite à la ligne 320 du fichier ./lib/private/util.php .

      Quand tu dis « lors de l’installation » tu parles de la toute première page, ou est-ce que cela apparaît plus tard ?

      Réponse
      • 14 avril 2015 à 16 h 49 min
        Permalink

        Bonjour et merci de la réponse,

        J’ai refait un essai d’installation de la 8.0.2

        Après transfert de l’ensemble des fichiers (9 202 transferts réussis) sur www/owncloud-8.0.2 , j’ai été sur l’interface web et il m’affiche :

        1
        2
        3
        Warning: Unexpected character in input: '\' (ASCII=92) state=1 in /home/unapeda/www/owncloud-8.0.2/index.php on line 38

        Parse error: syntax error, unexpected T_STRING, expecting T_VARIABLE in /home/unapeda/www/owncloud-8.0.2/index.php on line 38

        Je n’ai modifié aucun fichier.

        Mon fichier index.php

        1
        2
        3
        4
        5
        6
        7
        8
        9
        10
        11
        12
        13
        14
        15
        16
        17
        18
        19
        20
        21
        22
        23
        24
        25
        26
        27
        28
        29
        30
        31
        32
        33
        34
        35
        36
        37
        38
        39
        40
        41
        42
        43
        44
        45
        46
        47
        48
        49
        50
        51
        52
        53
        <?php

        /**
        * ownCloud
        *
        * @author Frank Karlitschek
        * @copyright 2010 Frank Karlitschek karlitschek@kde.org
        *
        * This library is free software; you can redistribute it and/or
        * modify it under the terms of the GNU AFFERO GENERAL PUBLIC LICENSE
        * License as published by the Free Software Foundation; either
        * version 3 of the License, or any later version.
        *
        * This library is distributed in the hope that it will be useful,
        * but WITHOUT ANY WARRANTY; without even the implied warranty of
        * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
        * GNU AFFERO GENERAL PUBLIC LICENSE for more details.
        *
        * You should have received a copy of the GNU Affero General Public
        * License along with this library.  If not, see <http://www.gnu.org/licenses/>.
        *
        */

        // Show warning if a PHP version below 5.4.0 is used, this has to happen here
        // because base.php will already use 5.4 syntax.
        if (version_compare(PHP_VERSION, '5.4.0') === -1) {
             echo 'This version of ownCloud requires at least PHP 5.4.0<br/>';
             echo 'You are currently running ' . PHP_VERSION . '. Please update your PHP version.';
             return;
        }

        try {
             
             require_once 'lib/base.php';

             OC::handleRequest();

        } catch(\OC\ServiceUnavailableException $ex) {
             \OCP\Util::logException('index', $ex);

             //show the user a detailed error page
             OC_Response::setStatus(OC_Response::STATUS_SERVICE_UNAVAILABLE);
             OC_Template::printExceptionErrorPage($ex);
        } catch (\OC\HintException $ex) {
             OC_Response::setStatus(OC_Response::STATUS_SERVICE_UNAVAILABLE);
             OC_Template::printErrorPage($ex->getMessage(), $ex->getHint());
        } catch (Exception $ex) {
             \OCP\Util::logException('index', $ex);

             //show the user a detailed error page
             OC_Response::setStatus(OC_Response::STATUS_INTERNAL_SERVER_ERROR);
             OC_Template::printExceptionErrorPage($ex);
        }

        J’ai eu la même erreur en essayant de prendre une version 7.0.5

        Merci des pistes

        Réponse
        • 16 avril 2015 à 7 h 43 min
          Permalink

          Si tu as la même erreur avec la v7, ce serait pas plutôt côté serveur ? Tu es sur du mutu OVH ? Est-ce que tu as testé le script PHP d’installation, des fois que ce soit ton client FTP qui foire un peu ? 🙂

          Réponse
        • 27 avril 2015 à 9 h 39 min
          Permalink

          Bonjour, As-tu bien installé owncloud dans un fichier appelé www ? pour moi, ça a résolu le problème.

          Réponse
        • 28 août 2015 à 21 h 25 min
          Permalink

          J’avais la même erreur, il suffit de modifier la version de php sur via le fichier .htaccess et tout roule.
          Ajoute :
          SetEnv PHP_VER 5_4
          au début de ton fichier et ça devrait être suffisant

          Réponse
  • 12 avril 2015 à 17 h 58 min
    Permalink

    Bonjour,
    Je viens d’installer la version 8.02 sur un OVH mutualisé : ça a l’air de marcher mais… j’ai maintenant le message d’erreur suivant en admin :
    Le jeu de caractères PHP n’est pas réglé sur UTF-8. Ceci peut entraîner des problèmes majeurs avec les noms de fichiers contenant des caractères non-ASCII. Nous recommandons fortement de changer la valeur de ‘default_charset’ dans php.ini par ‘UTF-8’.
    J’ai créé un php.ini dans le répertoire racine de owncloud mais ça ne change rien : sans doute pas pris en compte sur un mutualisé OVH ? Que faire ?
    Merci pour votre aide.

    Réponse
  • 14 avril 2015 à 15 h 54 min
    Permalink

    Bonjour,

    J’ai fait une nouvelle installation avec owncloud 7.0.5.

    Et là, j’ai une nouvelle erreur :

    1
    2
    3
    Warning: Unexpected character in input: '\' (ASCII=92) state=1 in /home/mysite/www/owncloud-7.0.5/index.php on line 30

    Parse error: syntax error, unexpected T_STRING, expecting T_VARIABLE in /home/mysite/www/owncloud-7.0.5/index.php on line 30

    Je n’ai pas touché à index.php.

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    <?php
     
    /**
    * ownCloud
    *
    * @author Frank Karlitschek
    * @copyright 2010 Frank Karlitschek karlitschek@kde.org
    *
    * This library is free software; you can redistribute it and/or
    * modify it under the terms of the GNU AFFERO GENERAL PUBLIC LICENSE
    * License as published by the Free Software Foundation; either
    * version 3 of the License, or any later version.
    *
    * This library is distributed in the hope that it will be useful,
    * but WITHOUT ANY WARRANTY; without even the implied warranty of
    * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    * GNU AFFERO GENERAL PUBLIC LICENSE for more details.
    *
    * You should have received a copy of the GNU Affero General Public
    * License along with this library.  If not, see <http://www.gnu.org/licenses/>.
    *
    */
     
    try {
     
         require_once 'lib/base.php';
     
         OC::handleRequest();
     
    } catch(\OC\ServiceUnavailableException $ex) {
         \OCP\Util::logException('index', $ex);
     
         //show the user a detailed error page
         OC_Response::setStatus(OC_Response::STATUS_SERVICE_UNAVAILABLE);
         OC_Template::printExceptionErrorPage($ex);
    } catch (Exception $ex) {
         \OCP\Util::logException('index', $ex);
     
         //show the user a detailed error page
         OC_Response::setStatus(OC_Response::STATUS_INTERNAL_SERVER_ERROR);
         OC_Template::printExceptionErrorPage($ex);
    }
    Réponse
  • 8 mai 2015 à 13 h 27 min
    Permalink

    Bonjour.

    Installation de la version 8.0.3 faite ce matin sur un hébergement mutualisé OVH à partir d’un Mac. Quelques précisions :
    – Je viens de comprendre que l’utilitaire de décompression intégré dans Mac OSX ignore superbement les fichiers cachés unix (en particulier les fichiers .htaccess). Utilisez autre chose pour décompresser l’archive .zip ou .tar.gz !
    – Un fichier .htaccess est compris dans l’archive Owncloud. Apparemment les scripts d’installation d’Owncloud vérifient maintenant la présence d’un numéro de version en commentaire dans ce fichier et génèrent une erreur si ce n’est pas le cas.

    1
    # Version: 8.0.3

    – J’ai quand même dû faire la modif 1 et intégré SetEnv PHP_VER 5_4 dans ce fichier juste après le commentaire de version sinon j’avais une erreur de syntaxe PHP.
    – Modif 2 faite également. Pas encore eu besoin de la 3.

    Merci beaucoup pour ce tuto Maxime ! 🙂

    Réponse
    • 11 mai 2015 à 8 h 18 min
      Permalink

      Salut,

      Pour le coup de l’extracteur de Mac OS… chapeau, ça pourra servir à d’autres. Je n’en savais rien, j’utilise pas cet OS… 🙂
      Merci à toi du retour !

      Content que ce tuto ait été suffisant pour t’aider dans cette installation !

      Réponse
  • 15 juin 2015 à 12 h 29 min
    Permalink

    J’ai installé la nouvelle version 8.0.3

    Les problèmes d’installation ont disparu.

    Je souhaite faire synchroniser une partie de mon PC avec une instance OwnCloud et une autre partie de mon PC avec une autre instance.

    Or après avoir installé ownCloud sur mon PC pour la 1ère instance, je ne sais pas comment créer une 2ème instance.(je ne sais pas si je suis clair). L’interface ne propose qu’un compte à synchroniser.

    Merci pour votre aide

    Réponse
  • 15 juin 2015 à 20 h 31 min
    Permalink

    Bonjour,

    OC m’indique 2 Avertissements :

    Avertissement de sécurité
    Vous accédez à ownCloud via HTTP. Nous vous recommandons fortement de configurer votre serveur pour forcer l’utilisation de HTTPS à la place.

    Le jeu de caractères PHP n’est pas réglé sur UTF-8
    Le jeu de caractères PHP n’est pas réglé sur UTF-8. Ceci peut entraîner des problèmes majeurs avec les noms de fichiers contenant des caractères non-ASCII. Nous recommandons fortement de changer la valeur de ‘default_charset’ dans php.ini par ‘UTF-8’.

    Comment obtenir https à partir d’un hébergement sur OVH ?
    Comment accéder à php.ini sur le site d’OVH ?

    Réponse
  • 16 juin 2015 à 20 h 29 min
    Permalink

    J’ai bien peur que ni l’un ni l’autre de soit possible

    Réponse
    • 17 juin 2015 à 8 h 01 min
      Permalink

      Non pas trop simple, c’est tout bon. En fait, sur un mutualisé, tu as bien droit à un certificat SSL mutualisé lui aussi ! Il est valable pour quelque chose comme sslXX.ovh.net, donc tu dois avoir un avertissement dans ton navigateur, mais c’est possible de l’utiliser. Tu peux même forcer ownCloud à passer par https (c’est mieux) !

      Pour le php.ini, j’avoue que je n’ai jamais eu ce souci d’encodage. Je vais faire là mise à jour 8.0.4 aujourd’hui, à voir…
      Dans le coup, tu peux regarder du côté du fichier .ovhconfig, mais c’est super limité. Ou peut-être en passant par le .htaccess, mais là encore…

      Réponse
  • 19 juin 2015 à 19 h 08 min
    Permalink

    Bonjour,
    Je vais poser une question un peu bête, mais lorsque l’on est en mutualisé ovh à 1,99 € (une base Mysql dispo) et que la base de données est déjà utilisé pour un site géré avec joomla, c’est possible ou pas d’installer Owncloud ?

    Merci d’avance

    Réponse
    • 19 juin 2015 à 21 h 08 min
      Permalink

      Bonsoir Patrick,

      S’il te reste 1 base de dispo, tu peux installer owncloud (s’il reste suffisamment d’espace…)

      Réponse
  • 20 juin 2015 à 7 h 53 min
    Permalink

    Bonjour et merci Kayou77.
    C’est bien ce que je craignais.

    Réponse
  • 21 juin 2015 à 12 h 17 min
    Permalink

    Bon, malgré tous mes efforts, je n’arrive pas à installer owncloud 8 sur mon serveur mutualisé OVH

    Après les modifications indiquées dans le tuto, lorsque j’accède à l’URL, j’obtiens systématiquement l’erreur suivante.

    Cannot write into « apps » directory

    This can usually be fixed by giving the webserver write access to the apps directory or disabling the appstore in the config file.

    Voilà le contenu du fichier config.php dans la partie qui concerne l’appstore

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    /**
     * The URL of the appstore to use.
     */
    'appstoreurl' => 'https://api.owncloud.com/v1',

    /**
     * Use the ``apps_paths`` parameter to set the location of the Apps directory,
     * which should be scanned for available apps, and where user-specific apps
     * should be installed from the Apps store. The ``path`` defines the absolute
     * file system path to the app folder. The key ``url`` defines the HTTP web path
     * to that folder, starting from the ownCloud web root. The key ``writable``
     * indicates if a web server can write files to that folder.
     */
    'apps_paths' => array(
        array(
            'path'=> '/home/nomdomaine/www/owncloud/apps',
            'url' => '/apps',
            'writable' => true,
        ),
    ),

    Je précise que l’intégralité de mon arborescence owncloud est accessible (chmod 777). Je sais c’est moche, mais je réglerais plus finement une fois l’installation terminée.

    Quelqu’un a une idée de comment résoudre ce problème ?

    Réponse
    • 21 juin 2015 à 13 h 16 min
      Permalink

      Bonjour,

      Je ne suis pas sur que ton chemin (path) soit le bon

      ‘path’=> ‘/home/nomdomaine/www/owncloud/apps

      Ton site nomdomaine est installé normalement sous www
      Et donc je ne vois pas trop ce que /home fait dans le chemin. /home correspondrait plutôt à une installation en local sur ton PC.

      Si tu as mis owncloud dans un sous répertoire de ton site, je verrai plutôt le chemin comme :

      ‘path’=> ‘www/nomdomaine/owncloud/apps’

      Cependant je n’ai pas une vision de ton arborescence.

      Peux-tu renvoyer l’adresse de ton site et indiquer où tu as mis owncloud : sous-répertoire de ton site ou autrement ?

      Réponse
  • 24 juin 2015 à 12 h 55 min
    Permalink

    Bonjour et merci pour ce tuto.
    Je viens d’installer OC, version 8.0.4 sur un espace mutualisé pro de OVH, avec quelques difficultés, mais j’ai fini par y arriver.
    La première difficulté venait du fait que mon client FTP (Filezilla) avait omis le fichier version.php, avec, comme conséquence, que j’obtenais une page blanche. Pour le moment, je n’ai fait que la modif 2. Quelqu’un a-t-il demandé à OVH ce qu’il fallait faire pour obtenir cet espace disque disponible ?
    Ce qui m’inquiète (serait-ce une coïncidence ?) OVH m’informe que je dois signer un nouveau contrat intitulé « CONDITIONS PARTICULIÈRES DU SERVICE OVH PUBLIC CLOUD »
    Or, je n’ai souscris à aucun nouveau service chez eux et je n’ai pas demandé de cloud chez eux. Serait-ce une espèce d’interdiction d’utiliser ownercloud ?
    Pour répondre à la question précédente, le path du répertoire, chez OVH est bien du style : /home/nom_du_domaine/www si le logiciel est mis sous la racine www.

    Réponse
  • 24 juin 2015 à 13 h 48 min
    Permalink

    Re-bonjour.

    J’ai essayé en vitesse de récupérer mon espace disque en utilisant la commande « du »
    Sachant que j’ai 250 Go d’espace en tout, je récupère, dans une variable, le résultat de la commande « du -sh /home/mon_domaine_principal ». Il suffit de manipuler le résultat et d’ôter à 250 G0 le premier élément du tableau résultat (ce que je n’ai pas encore fait, faute de temps).

    1
    2
    3
    4
    5
    <?php
    $path=getcwd ();
    $path1=$path."/..";
    $utilise = system ("du -sh $path1");
    ?>
    Réponse
  • 30 juin 2015 à 13 h 50 min
    Permalink

    Bonjour,

    j’utilisais jusqu’à présent la version 6 de OwnCloud sur un mutualisé chez ovh.
    La mise à jour « assistée » d’une version majeure de OC à une autre n’étant pas possible, j’ai tout supprimé et envoyé par FTP la version 8.0.4.

    Lorsque je me rends à l’URL de OC (www/nuage/owncloud), j’obtiens l’erreur suivante :

    1
    2
    3
    Warning: Unexpected character in input: '\' (ASCII=92) state=1 in /home/monIdentifiant/www/nuage/owncloud/index.php on line 38

    Parse error: syntax error, unexpected T_STRING, expecting T_VARIABLE in /home/monIdentifiant/www/nuage/owncloud/index.php on line 38

    Auriez-vous une idée de solution ?
    Merci.

    Réponse
    • 30 juin 2015 à 15 h 37 min
      Permalink

      Bonjour.
      Pas de solution mais as-tu vérifié la concordance entre tes fichiers en local et sur le serveur ?
      Avec Filezilla (je ne connais pas les autres), il arrive qu’un fichier soit manquent ou ait mal été écrit. Avec Filezilla , un « Cntrl o » permet de vérifier. C’est, à mon sens, la première des choses à faire.

      Réponse
      • 30 juin 2015 à 16 h 03 min
        Permalink

        Bonjour,
        merci pour ta réponse.
        C’est résolu. Je pensais avoir modifié le .htaccess pour forcer à utiliser PHP 5.4 mais ne je ne l’avais pas fait…
        Maintenant, tout roule !

        Réponse
        • 30 juin 2015 à 16 h 13 min
          Permalink

          Je n’ai pas pensé à ça vu que je suis par défaut en php5 chez OVH.
          Tant mieux si ça roule.

          Réponse
          • 30 juin 2015 à 16 h 21 min
            Permalink

            Mon mutualisé est en PHP 5.2.7. J’ai reçu un email d’OVH m’informant que prochainement seules les versions 5.4, 5.5 et 5.6 de PHP seraient supportées. D’où la réinstallation pour ne pas me retrouver en carafe.

  • 30 juin 2015 à 16 h 29 min
    Permalink

    À la racine de ton espace client, c’est-à dire au même niveau que tes www, tu dois avoir un fichier .ovhconfig
    Dans ce fichier, j’y ai mis :

    1
    2
    3
    4
    app.engine=php
    app.engine.version=5.4
    http.firewall=none
    environment=production

    ce qui me met mon php à 5.4 pour tous mes sites; plus besoin de préciser dans .htaccess.

    Réponse
  • 2 juillet 2015 à 23 h 12 min
    Permalink

    Bonjour.
    J’utilise oc sur un serveur perso sans embrouilles mais là je test sur mon mutu ovh et j’ai une galère: je nep eux pas changer d’email dans le menu « perso » jj’ai été obligé carrément de créer la table sql pour le faire .
    Et maintenant quand je veux changer de mail ça marque « …enregistrement » mais ça reste figé et ça change rien du coup. Vous aussi ?

    Réponse
    • 5 juillet 2015 à 9 h 58 min
      Permalink

      Pas de problème dans mon cas (mutu ovh), OC 8.0.4.

      Réponse
  • 5 juillet 2015 à 11 h 44 min
    Permalink

    Bonjour.
    Je n’ai pas eu de problème pour mettre mon adresse courriel. En revanche, suite à ton post, j’ai essayé de la changer : ça me met « adresse invalide » et l’ancienne adresse est remise.
    Je n’a pas essayé mais peut-être faut-il que les adresses Serveur mail et adresse perso soient les mêmes ? Ce serait une aberration, mais …

    Réponse
    • 6 juillet 2015 à 16 h 16 min
      Permalink

      Moi ça n’a carrément aucun effet, faut que je réinstalle pour testerparceque bon passer par phpmyadmin à chaque fois c’est pas une solution quoi

      Réponse
  • 7 juillet 2015 à 17 h 46 min
    Permalink

    bon bin j’ai tout virer pour passer a la version 8.1 et toujours les même soucis.

    dans les logs j’ai ça >>

    Automatically populating $HTTP_RAW_POST_DATA is deprecated and will be removed in a future version. To avoid this warning set ‘always_populate_raw_post_data’ to ‘-1’ in php.ini and use the php://input stream instead. at Unknown#0

    et ça >>>

    Zend OPcache API is restricted by « restrict_api » configuration directive at /home/x/CLOUD/lib/private/util.php#1354

    voilà, donc je suis bloqué quoi..

    Réponse
  • 7 juillet 2015 à 19 h 12 min
    Permalink

    Là, je ne vois pas et je n’ai pas le temps de regarder : demain, lever à 5 h pour emmener mes petits-enfants à Europa Park.
    Je n’ai pas eu de souci particulier pour installer chez OVH; j’ai suivi le guide (trouvé sur github.com je crois) et ça a marché tout de suite. Tu as quelle formule d’hébergement ?

    Réponse
    • 7 juillet 2015 à 22 h 05 min
      Permalink

      c’est un perso2014 , là je teste en sous domaine je vais faire quelques test pour voir mais je pense que c’est la version php qui pose soucis..
      j’utilise:
      PHP: 5.6.6
      MySQL: 5.1.73-2+squeeze+build1+1

      Réponse
    • 7 juillet 2015 à 22 h 34 min
      Permalink

      ffff là que j’avais 5min leur ftp est dans les choux complet , bon bin on verra plus tard désolé.
      par contre j’ai testé toutes les versions de php et ça ne change rien (c’est déjà ça d’écarté..)

      Réponse
    • 8 juillet 2015 à 16 h 01 min
      Permalink

      bon j’ai plein d’autre erreurs lol l’app « document  » je crois que OVH-mutu c’est bien pour un petit site des années 80 en html mais pas plus quoi.

      allez, j’abandonne , bon courage a tous et merci pour ces tutos quand-meme

      Réponse
  • 8 juillet 2015 à 13 h 22 min
    Permalink

    bon après moultes galères j’ai enfin reussi , je pensais que quand vous parliez de parefeu c’était celui du manager mais en fait dans le « .ovhconfig  » qui est a la racine il faut la ligne :
     » http.firewall=none  »
    voilà , par contre j’ai tout un tas d’erreurs concernant l’optimisation faite par le .htaccess a croire que les options ne sont pas reconnues..?.^^
    pourtant il est bien prit en compte j’ai testé avec une limitation par .passwd pour tester
    ..

    Réponse
    • 9 juillet 2015 à 13 h 14 min
      Permalink

      Bonjour.
      Je ne suis pas sponsorisé par OVH, mais « OVH-mutu c’est bien pour un petit site des années 80 en html mais pas plus », je ne suis pas d’accord ! Je pense que tu as du lâcher ça dans un moment de colère … J’ai 4 sites en mutualisé qui fonctionnent très bien.
      Voici ce que j’ai dans mon .ovhconfig :

      1
      2
      3
      4
      app.engine=php
      app.engine.version=5.4
      http.firewall=none
      environment=production

      Suite à ton message, j’ai quand même regardé mes fichiers logs et, en effet, il y a d’innombrables erreurs, mais ça fonctionne, c’est le principal.

      Réponse
      • 9 juillet 2015 à 20 h 56 min
        Permalink

        oui je disais ça en éxagérant un peu mais c’est toujours les même soucis avec les mutu, c’est trop bridé , j’ai moi aussi plusieurs sites sous jooomla,WP et piwigo qui tournent plus que bien , mais tout ne marche pas forcément en mutu, je me souviens avoir galéré avec d’autres cms, bref…

        mes messages se sont un peu mélangé, j’en parle plus haut du « .ovhconfig » ça a réglé le soucis du changement de mail, par contre je suis en php5.6 perso.

        je rententerai plus tard on verra bien…

        Réponse
  • 10 juillet 2015 à 22 h 59 min
    Permalink

    Bonjour,
    Je suis passé de OC 8.0.4 (SQLite) à OC 8.1 (MySQL) chez OVH.
    Tout est fonctionnel sauf ma connection avec le client (je suis sous DEBIAN 8).
    Impossible donc de me connecter bien que mon couple ID/mot de passe soit correct et fonctionnel.
    Pour info, j’arrive à me connecter en webdav via Nautilus.

    J’ai fait plein de test avec différentes config de mon fichier config.php.

    A l’aide ;o)

    Réponse
    • 11 juillet 2015 à 7 h 26 min
      Permalink

      Bonjour. Comme on se retrouve !
      Est-ce que tu as installé OC client ?
      Si oui, l’as-tu ré-installé depuis que tu es en 8.1 ?
      Pour ma part, je garde les 2 installations, chez OVH, la 8.0.4 et la 8.1 et mon client local pointe sur l’installation ancienne. Je ne changerai que lorsque la 8.01 fonctionnera sans trop de messages d’erreur.
      Je viens de faire un essai : même chose que toi : pb. de connexion.
      As-tu lu ceci : doc.owncloud

      Réponse
  • 11 juillet 2015 à 7 h 55 min
    Permalink

    En revanche, l’accès et la synchro depuis mon smartphone fonctionne très bien.

    Réponse
  • 24 juillet 2015 à 16 h 46 min
    Permalink

    Bonjour,

    tout d’abord un grand merci pour ce tuto et pour tous ces commentaires d’une aide précieuse. J’ai installé ownCloud (sur un mutu OVH donc) et sur un sous-domaine, et certains fichiers js ne se chargent pas (mais mis en erreur 403), à priori à cause de l’erreur suivante qui apparaît dans la console :
    Error parsing header X-XSS-Protection: 1; mode=block, 1; mode=block: expected semicolon at character position 14. The default protections will be applied.

    Quelqu’un a t’il déjà eu ce problème ou saurait-il m’aider à le résoudre ?

    Un grand merci d’avance.

    Réponse
    • 1 août 2015 à 14 h 10 min
      Permalink

      Bonjour.

      La réponse est dans la question … tu devrais avoir quelque part; soit dans ton .htaccess soit dans un générateur php, soit dans un fichier de config

      1
       X-XSS-Protection" content="1; mode=block"

      avec un point virgule après le 1
      Soit le point-virgule manque, soit il y a une ponctuation de trop ou manquante dans la ligne.

      Réponse
    • 1 août 2015 à 14 h 20 min
      Permalink

      Re
      Si tu arrives à avoir une page administration à peu près vierge d’erreur, fais moi signe S.T.P. : ça fait quelques jours que je galère pour trouver des solutions …

      Réponse
  • 17 août 2015 à 9 h 32 min
    Permalink

    Bonjour,

    Un détail : il y a me semble-t-il une petite faute de frappe dans la section « Modif 2 » (local.php) : si la première ligne est 266, la seconde est plutôt 267 ou 268 que 227. (Chez moi, en version 8.1.1, c’est respectivement 265 et 267.)

    J’ai réussi l’installation sans trop de problème. Après l’étape de l’identification MySQL, le navigateur a affiché une page blanche (…index.php/apps/files/). Mais ce n’est pas grave, en revenant à la racine de l’installation d’OwnCloud (index.php) cela fonctionnait.

    Réponse
  • 17 août 2015 à 9 h 42 min
    Permalink

    @thbz : oui, tu dois avoir raison, mais je crois que cette doc est obsolète. Il n’y a plus, je pense, à modifier ce fichier local.php

    Réponse
  • 17 août 2015 à 15 h 25 min
    Permalink

    Bonjour,

    je suis également confronté à de nombreuses erreurs php sur la page administration, et ce, depuis le passage à la version 8.1.1. Je suis chez OVH et j’ai configuré le .ovhconfig en version 5.5 (cela donne la version 5.5.22 si je ne me trompe…). Je me pose quelques questions :
    – certains suggèrent de commenter des lignes dans le .htaccess afin de faire disparaître, par exemple, les erreurs des en-têtes HTTP (X-XSS-Protection – X-Robots-Tags etc), mais ne vaut-il pas mieux “vivre” avec ces erreurs en attendant de trouver une solution plutôt que de les cacher “sous le tapis” ? Quel risque prend-on en masquant ces lignes ou en neutralisant des alertes de sécurité ?
    – L’avertissement qui se trouve en début d’article sur le fait qu’il n’est pas possible d’exécuter la mise à jour automatique d’OC lorsqu’on on est hébergé en mutualisé chez OVH est-il toujours d’actualité ? Je l’ai fait par deux fois et cela s’est toujours bien passé…
    – Avez-vous déplacé votre dossier “data” ailleurs que dans le répertoire owncloud, et si oui, à quel endroit, pour quelle raison, et de quelle façon ?

    Merci pour vos réponses, et bravo pour ce soutien “en français dans le texte » !

    Réponse
    • 17 août 2015 à 15 h 47 min
      Permalink

      Bonjour.
      Je ne suis pas assez calé en accès Web pour être certain de ce que j’avance, mais je crois que les en-têtes que tu cites devraient se trouver dans les balises meta de nos fichiers html. Le fait de les enlever du fichier .htaccess ne doit rien modifier à la sécurité. À vérifier.
      J’ai, moi aussi, testé la mise à jour ‘on-line’ et tout s’est bien passé.
      Je n’ai plus de répertoire data : je l’ai déplacé au même niveau que les répertoires www et modifié le fichier de config en conséquence : ‘datadirectory’ => ‘/home/mondomaine/Mesdata’,
      en remplacant, évidemment mondamaine et Mesdata par les bonnes valeurs. 9a c’est passé sans heurt.

      Réponse
      • 17 août 2015 à 16 h 07 min
        Permalink

        Ok, je vais essayer de déplacer mon dossier data, j’imagine que le but est de le mettre en sécurité en dehors du répertoire http://www..?

        Je préfère avancer doucement avec les versions de php, car la version choisie dans .ovhconfig vaut pour tout l’hébergement, donc pas de php à la carte selon l’appli qu’on utilise dans tel ou tel répertoire. Je garde donc une version compatible au maximum avec l’ensemble de l’hébergement (si j’ai bien tout compris…).

        Do coup, une autre question : faut-il s’alerter de cet avertissement : “Votre dossier de données et vos fichiers sont probablement accessibles depuis internet. Le fichier .htaccess ne fonctionne pas.” ce qui est apparemment faux…

        Réponse
        • 17 août 2015 à 16 h 09 min
          Permalink

          désolé, je me suis emmêlé dans les balises de citation…

          Réponse
  • 17 août 2015 à 16 h 12 min
    Permalink

    Bonsoir. En effet, en déplaçant les données en dehors du répertoire http://www. elles deviennent inaccessibles aux malveillants et on n’a plus le message d’avertissement.
    En ce qui concerne php 5.6 chez OVH, mes sites en Joomla, Piwigo, Webtrees et un site en développement perso passent sans problème.

    Réponse
  • 8 septembre 2015 à 9 h 05 min
    Permalink

    Bonjour,
    Je suis débutant…
    J’ai suivi les indications pour l’installation d’Owncloud dans mon hébergement OVH mais j’ai ce message d’erreur (ci-dessous) et je ne sais pas comment le régler ?

    [code]App directory « /var/www/owncloud/apps » not found! Please put the ownCloud apps folder in the ownCloud folder or the folder above. You can also configure the location in the config.php file.[/code]

    Une idée amie ?

    D’avance merci

    Réponse
    • 8 septembre 2015 à 10 h 18 min
      Permalink

      Bonjour.
      Moi aussi, je suis débutant sur OC.
      Ton nom de domaine apparaît bien dans ton fichier config.php ?
      Chez moi, il apparaît plusieurs fois :
      [code]array (
      0 => ‘mon.domaine.fr’,
      1 => ‘www.mon.domaine.fr’,
      ),
      ‘datadirectory’ => ‘/home/mondomaine/Musique’,
      ‘overwrite.cli.url’ => ‘https://mon.domaine.fr’,
      [/code]
      Dans cet exemple, mon est le nom du sous.domaine où j’ai fait l’istallation et domine, le nom du domaine.
      Je ne vois rien d’autre.

      Réponse
      • 8 septembre 2015 à 17 h 15 min
        Permalink

        Merci…

        Bizarre qu’il me donne « /usr/local/bin:/usr/bin:/bin » comme résultat !?

        Cependant j’ai dû créer le dossier « data » sous « owncloud » car il n’existait pas.

        J’ai donné tous les droits possibles !

        Question : quelles étaient tes démarches pour arriver à un bon résultat sur OVH ?

        Merci encore

        Réponse
        • 8 septembre 2015 à 17 h 26 min
          Permalink

          Décidément, ce forum est bizarre : je reçois ta réponse sur ma messagerie mais elle ne s’affiche pas ici !
          1) Le getcwd () ne doit pas te donner /usr/local/bin:/usr/bin:/bin , ou alors, c’est que tu n’es pas en mutualisé. Mais même : getcwd (get current directory) doit te donner le répertoire d’où il est lancé.
          2) Comme pour chaque nouveau progiciel que je teste, j’essaie d’abord en local, puis je recopie mon site local par ftp. Ça a marché et j’ai essayé une seconde install, directement sur le site, qui a fonctionné également. J’ai toujours des messages d’erreur, mais le site fonctionne, c’est le principal.

          Réponse
    • 8 septembre 2015 à 10 h 20 min
      Permalink

      Bonjour.
      Moi aussi, je suis débutant sur OC.
      Ton nom de domaine apparaît bien dans ton fichier config.php ?
      Chez moi, il apparaît plusieurs fois :
      [code]
      ‘trusted_domains’ =>
      array (
      0 => ‘mon.domaine.fr’,
      1 => ‘www.mon.domaine.fr’,
      ),
      ‘datadirectory’ => ‘/home/mondomaine/Musique’,
      ‘overwrite.cli.url’ => ‘https://mon.domaine.fr’,
      [/code]
      Dans cet exemple, mon est le nom du sous.domaine où j’ai fait l’istallation et domine, le nom du domaine.
      Je ne vois rien d’autre.

      Réponse
      • 8 septembre 2015 à 10 h 57 min
        Permalink

        Merci d’avoir pris le temps de me répondre jbyvosges…

        J’ai fait ceci dans config.php

        ‘trusted_domains’ =>
        array (
        ‘mon.domaine.com’,
        ‘www.mon.domaine.com’,
        ),

        ‘datadirectory’ => ‘/home/mon.domaine/owncloud’,

        ‘apps_paths’ => array(
        array(
        ‘path’=> ‘/home/mon.domaine/owncloud/apps/’,
        ‘url’ => ‘/apps’,
        ‘writable’ => true,
        ),
        ),

        owncloud est le dossier où sont présents les fichiers…

        Mais j’ai toujours le message :

         » App directory « /home/mon.domaine/owncloud/apps » not found! Please put the ownCloud apps folder in the ownCloud folder or the folder above. You can also configure the location in the config.php file.  »

        Grrr ça m’énerve !!!

        Réponse
  • 8 septembre 2015 à 11 h 21 min
    Permalink

    Re bonjour.
    En effet, il y a quelque chose de bizarre dans ta config. Je n’ai jamais vu de ‘apps_paths’ chez moi et n’en vois pas l’utilité.
    Voilà comment j’ai fait (mais ce n’est peut-être pas la seule solution) : j’ai créé un sous domaine (je l’ai appelé testb, au départ, c’était juste un test) qui pointe vers un répertoire, par exemple owncloud qui est directement sous la racine de mes sites, c’est à dire au même niveau que les www.
    Pour un mutualisé OVH, le répertoire réel est quelque chose comme /home/mondomaine/owncloud où l’on trouve les répertoires d’OC : settings, 3dparty, apps etc…
    As-tu bien un répertoire apps ?
    En revanche, il me paraît impossible de mettre, comme tu l’as fait, le répertoire des données (data) sous /home/mon.domaine/owncloud ! Au pire, les données doivent être sous /home/mon.domaine/owncloud/data ou mieux, sous un répertoire en dehors de tes sites, par exemple /home/mon.domaine/MesDonnees (répertoire qu’il faut créer). Corriges donc cette erreur et dis moi ce que ça donne.

    Réponse
    • 8 septembre 2015 à 11 h 46 min
      Permalink

      En effet, j’ai fait exactement comme toi :

      J’ai installé un sous-nom.de.domaine sous OVH et pointé vers le répertoire que j’ai crée et nommé « owncloud ».

      Le repertoire « APPS » existe bel et bien sous « owncloud » ainsi que celui « DATA »…

      Du coup j’ai changé dans config.php et je fais ceci :

      ‘trusted_domains’ =>
      array (
      0 => ‘sous-domaine.mon-domaine.com’,
      1 => ‘www.sous-domaine.mon-domaine.com’,
      ),

      ‘datadirectory’ => ‘/home/sous-domaine.mon-domaine.com/owncloud/data’,

      ‘apps_paths’ => array(
      array(
      ‘path’=> ‘/home/sous-domaine.mon-domaine.com/owncloud/apps/’,
      ‘url’ => ‘/apps’,
      ‘writable’ => true,
      ),
      ),

      PS.: j’ai testé sans le « .COM »

      MAIS TOUJOURS RIEN !

      Je désespérè !

      Réponse
  • 8 septembre 2015 à 11 h 51 min
    Permalink

    Ça ne va toujours pas à mon sens.
    Si ton sous domaine pointe vers owncloud, ce nom devient en quelque sorte transparent et tu dois avoir :

    ‘datadirectory’ => ‘/home/sous-domaine.mon-domaine.com/data’,
    puisque owncloud et sous-domaine sont la même chose
    ‘apps_paths’ => array(
    array(
    ‘path’=> ‘/home/sous-domaine.mon-domaine.com/owncloud/apps/’,
    ‘url’ => ‘/apps’,
    ‘writable’ => true,
    ),
    ),
    de mon fichier de config.
    J’essaierai également de supprimer

    Réponse
    • 8 septembre 2015 à 12 h 09 min
      Permalink

      Merci encore…

      Alors ça évolue…

      Avant de faire ton test j’avais mis
      ‘apps_paths’ => array(
      array(
      ‘path’=> ‘/home/sous-domaine.mon-domaine.com/owncloud/apps/’,
      ‘url’ => ‘/apps’,
      ‘writable’ => true,
      ),
      ),
      En commenaire…
      Ensuite je fais :
      ‘datadirectory’ => ‘/home/mon-domaine/owncloud/data’,
      Et là j’ai obtenu la page principale d’owncloud avec le message suivant :

      « Sample configuration detected
      It has been detected that the sample configuration has been copied. This can break your installation and is unsupported. Please read the documentation before performing changes on config.php »

      Pour ton test j’ai obtenu :
      Path est égal à /usr/local/bin:/usr/bin:/bin

      Peux-tu m’aider encore pour la suite ?

      Réponse
  • 8 septembre 2015 à 11 h 57 min
    Permalink

    Pou plus de certitude, mets un fichier test.php sous owncloud, dans le quel tu mets :
    <?php
    echo " Path est égal à " . getenv("PATH") . " »;
    ?>

    lance le (normalement par /home/sous-domaine.mon-domaine.com/test.php et note la réponse. C’est cette réponse que tu dois mettre comme répertoire d’accès à tes données (à mon avis sans le .com)

    Réponse
  • 8 septembre 2015 à 12 h 03 min
    Permalink

    Oups, j’ai écrit trop vite.
    La commande à mettre dans le fichier test.php est getcwd() :

    <php?
    echo " Path est égal à " . getcwd() . " « ;
    ?>

    Réponse
    • 8 septembre 2015 à 13 h 06 min
      Permalink

      J’avais fait les corrections…

      Je vais continuer à bidouiller pour voir…

      Réponse
  • 8 septembre 2015 à 12 h 19 min
    Permalink

    C’est curieux, ce forum modifie ce que j’écris !
    après getcwd() , il y a un point, puis br entre «  » soit  »  » ; en enlevant les caractères blancs.
    Je dois partir bientôt. Je serais der etour vers 15 h 30.

    Réponse
    • 8 septembre 2015 à 14 h 00 min
      Permalink

      En poursuivant sans la partie :
      ‘apps_paths’ => array(
      array(
      ‘path’=> ‘/home/sous-domaine.mon-domaine.com/owncloud/apps/’,
      ‘url’ => ‘/apps’,
      ‘writable’ => true,
      ),
      ),
      Que j’ai mis en commentaire…

      Désormais j’obtiens une page qui me demande les codes sql mais affiche le message suivant :

      Error
      Can’t create or write into the data directory /home/domaine/owncloud/data

      Grrrrr

      j’arrive désormais

      Réponse
  • 8 septembre 2015 à 14 h 42 min
    Permalink

    Me voici de retour.

    Il semble que l’on avance … lentement mais sûrement.
    Le résultat de la commande getcwd() devrait donner quelque chose comme /home/domaine/owncloud
    Est-ce que le répertoire data est en lecture/écriture/exécution pour toi ?
    Le mien est en 750 (rwx-rx–)
    Est-ce que ton fichier config.php est en lecture/écriture pour toi ? (600)
    Est-ce que le fait de visiter ton cloud a modifié ce fichier de config ?
    Sinon, le mieux serait d’effacer ton installation et de ré-installer. Pour moi, ça s’est passé sans problème.

    Réponse
  • 8 septembre 2015 à 17 h 28 min
    Permalink

    De plus en plus étrange : ma réponse s’affiche en haut du site, à 17 h 27, alors qu’il est 18 h 26 !

    Réponse
    • 9 septembre 2015 à 12 h 55 min
      Permalink

      Hello l’ami,

      Je reviens vers toi pour te demander s’il était possible d’avoir ton fichier « config.php » comme modèle afin de voir où ça cloche chez moi…
      Bien évidement tu caches les adresses importantes !
      Je ne comprends pas !
      J’ai la page bleu de « settings » mais il ne trouve pas l’adresse du dossier data !!!???

      Réponse
      • 9 septembre 2015 à 13 h 10 min
        Permalink

        Bonjour.
        Le dossier data est automatiquement créé lors de l’installation, sous la racine de owncloud.
        À ta place, je dézipperai le fichier original en local et, sans rien installer, je recopierai le tout sur le serveur, sous le répertoire Owncloud, avec un client FTP (Filezilla par exemple).
        Avec Filezilla, tu peux vérifier que les fichiers sont les mêmes sur le serveur qu’en local et qu’ils ont bien tous été recopiés.
        Avant, tu peux tenter un truc : dans ta config, mets ‘installed’ => false, et accède à ton adresse Web.
        Encore avant, crée un répertoire data sous owncloud.
        Voici mon fichier de config, en espérant que le forum ne modifie pas le code (j’ai vu que l’on ne pouvait pas utiliser les BB codes) :
        ‘xxxxxxxxxxxx’,
        ‘passwordsalt’ => ‘xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx’,
        ‘secret’ => ‘xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx’,
        ‘trusted_domains’ =>
        array (
        0 => ‘testb.dolman.fr’,
        1 => ‘www.testb.dolman.fr’,
        ),
        ‘datadirectory’ => ‘/home/dolman/Musique’,
        ‘overwrite.cli.url’ => ‘https://testb.dolman.fr’,
        ‘dbtype’ => ‘mysql’,
        ‘version’ => ‘8.1.1.3’,
        ‘dbname’ => ‘xxxxxxxxxxxx’,
        ‘dbhost’ => ‘xxxxxxxxxxxx’,
        ‘dbtableprefix’ => ‘oc3_’,
        ‘dbuser’ => ‘xxxxxxxxxxxx’,
        ‘dbpassword’ => ‘xxxxxxxxxx’,
        ‘logtimezone’ => ‘UTC’,
        ‘installed’ => true,
        ‘theme’ => ‘MonNuage’,
        ‘mail_from_address’ => ‘xxXXXx’,
        ‘mail_smtpmode’ => ‘php’,
        ‘mail_domain’ => ‘yahoo.fr’,
        ‘forcessl’ => ‘true’,
        ‘forceSSLforSubdomains’ => true,
        ‘maintenance’ => false,
        ‘check_for_working_htaccess’ => false,
        ‘loglevel’ => 2,
        ‘config_is_read_only’ => false,
        ‘memcache.local’ => ‘\\OC\\Memcache\\ArrayCache’,
        );

        Un truc qui me vient à l’esprit : ta base de données ‘dbname’ existe bien ?
        tiens moi au courant.

        Réponse
  • 9 septembre 2015 à 13 h 13 min
    Permalink

    Bon, pas moyen d’afficher ces lignes ! quel m… ce forum wordpress !

    Réponse
    • 9 septembre 2015 à 13 h 45 min
      Permalink

      ‘instanceid’ =>  »,
      ‘passwordsalt’ =>  »,
      ‘secret’ =>  »,

      ‘datadirectory’ => ‘/home/mondnsprincipal/owncloud’,

      ‘version’ =>  »,

      ‘installed’ => false,

      ‘theme’ =>  »,

      ‘mail_smtpmode’ => ‘sendmail’,

      ‘forcessl’ => ‘true’, > JE N’AI PAS CECI !
      ‘forceSSLforSubdomain’ => true, > CELUI-CI NON PLUS !

      ‘check_for_working_htaccess’ => true,

      ‘memcache.local’ => ‘\OC\Memcache\APCu’,

      Le reste c’est pareil…

      Là j’obtiens :

      Erreur
      Impossible de créer, ou d’écrire dans, le répertoire des données /home/mondnsprincipal/owncloud

      Le repertoire « owncloud » est authorisé sur 705 !

      Ma ‘dbname’ existe bien !

      Réponse
  • 9 septembre 2015 à 13 h 48 min
    Permalink

    ‘datadirectory’ => ‘/home/mondnsprincipal/owncloud/data’, !!

    Il manque le data
    pour les 2 lignes forceSSL, ce n’est pas urgent de les mettre. Tu verras ca quand tout fonctuionnera

    Réponse
    • 9 septembre 2015 à 14 h 03 min
      Permalink

      Je l’ai ajouté mais rien à faire !

      J’ai aussi contacté OVH mais ils déclinent toute aide pour cette installation !

      Pour info j’ai un « hébergement perso » et toi ?

      J’ai aussi trouvé ceci : https://doc.owncloud.org/server/8.1/admin_manual/installation/installation_wizard.html

      Avec un script à faire tourner mais je ne sais pas où ou comment :

      #!/bin/bash
      ocpath=’/var/www/owncloud’
      htuser=’www-data’
      htgroup=’www-data’

      find ${ocpath}/ -type f -print0 | xargs -0 chmod 0640
      find ${ocpath}/ -type d -print0 | xargs -0 chmod 0750

      chown -R root:${htuser} ${ocpath}/
      chown -R ${htuser}:${htgroup} ${ocpath}/apps/
      chown -R ${htuser}:${htgroup} ${ocpath}/config/
      chown -R ${htuser}:${htgroup} ${ocpath}/data/
      chown -R ${htuser}:${htgroup} ${ocpath}/themes/

      chown root:${htuser} ${ocpath}/.htaccess
      chown root:${htuser} ${ocpath}/data/.htaccess

      chmod 0644 ${ocpath}/.htaccess
      chmod 0644 ${ocpath}/data/.htaccess

      En tout cas mille merci pour ton temps !
      Dommage pour moi…

      Réponse
  • 9 septembre 2015 à 14 h 24 min
    Permalink

    Oui, on ne peut pas compter sur OVH puis qu’ils proposent des clouds …
    Le shell script : impossible sur un mutu. Mais il ne sert pas à grand chose : on peut faire la même chose à ma main : ton répertoire data doy-être en 750 ou 700 et ton fichier de config en 640 ou 600.
    J’ai un hébergement pro, mais c’est à peu près la même chose, sauf que j’ai plus d’espace disque et base de données.
    Tu utilises php 5.6 ?
    À la racine de ton domaine, tu dois avoir un fichier « .ovhconfig » qui contient ces 4 lignes :
    app.engine=php
    app.engine.version=5.6
    http.firewall=none
    environment=production

    Mais, à mon avis, tu perds trop de temps : recommence l’installation en recopiant les fichiers de ton ordi vers le site : normalement, ça fonctionne du premier coup avec juste quelques messages d’erreur.

    Voici ce que tu devrais avoir comme réperoires et fichiers; vérifie qu’il n’en manque pas :
    owncloud/3rdparty/
    owncloud/apps/
    owncloud/config/
    owncloud/data/
    owncloud/core/
    owncloud/l10n/
    owncloud/lib/
    owncloud/ocs/
    owncloud/ocs-provider/
    owncloud/settings/
    owncloud/themes/
    owncloud/AUTHORS
    console.php
    COPYING-AGPL
    cron.php
    db_structure.xml
    owncloud/index.html
    owncloud/index.php
    owncloud/indie.json
    owncloud/occ
    owncloud/public.php
    owncloud/remote.php
    owncloud/robots.txt
    owncloud/status.php
    owncloud/version.php
    owncloud/.htaccess
    owncloud/.mailmap
    owncloud/.tag
    owncloud/.user.ini

    Réponse
    • 9 septembre 2015 à 15 h 25 min
      Permalink

      Hello l’ami !

      C’est réussi !

      En effet, j’ai dû créer un fichier .config avec la version PHP = 5.5 et j’ai aussi tout remis à nouveau dans mon espace…
      Il a l’air de bien fonctionner !
      Est-tu content de cette appli ?

      Encore une fois merci…

      Bonne journée à toi !

      Réponse
      • 9 septembre 2015 à 15 h 39 min
        Permalink

        Petite question :

        Peut-on changer l’espace disque après installation ?

        return \OC\Files\SPACE_UNKNOWN;

        Réponse
  • 9 septembre 2015 à 15 h 36 min
    Permalink

    Ouf ! Content que ça fonctionne enfin.
    Je suis assez content de cette appli pour le peu que j’en fait : je m’en sers juste pour sauvegarder toute ma musique sur un nuage et certains fichiers sensibles.
    Il y a des points cependant qui me hérissent : presque toutes les explications sont données pour des serveurs non mutualisés (modification des fichiers de config apache, php etc.). Du coup, on obtient des messages d’erreurs qu’on ne peut pas corriger.
    Je n’ai jamais réussi à faire fonctionner mozilla_sync, mais depuis la version 8, OC semble ne plus supporter cette appli.
    Ce qu’il y a de sûr , c’est que j’ai abandonné tous les autres nuages : Dropbox, Ubuntu one, Google etc. Je sais où sont mes données et je gère tout.

    Bonne utilisation à toi.

    Réponse
    • 9 septembre 2015 à 15 h 43 min
      Permalink

      Je ne sais pas si tu as reçu mon dernier message…

      Peut-on changer l’espace disque après installation ?

      return \OC\Files\SPACE_UNKNOWN;

      PS.: je vais installer le Client et l’appli smartphone dès que j’en aurai un nouveau (j’ai perdu mon wiko cet été)…

      A+

      Réponse
  • 9 septembre 2015 à 15 h 37 min
    Permalink

    PS. J’ai installé l’appli owncloud sync sur mon smartphone (je l’ai trouvée gratis) et j’ai mis Oncloud Client sur mes PC. Ça fonctionne au poil.

    Réponse
    • 9 septembre 2015 à 15 h 52 min
      Permalink

      Autre question après j’arrete :

      J’ai plein de message dans l’Administration toi aussi ?

      Genre :

      + php ne semble pas être configuré de manière à récupérer les valeurs des variables d’environnement. Le test de la commande getenv(« PATH ») retourne seulement une réponse vide.

      – Aucun cache de la mémoire n’est configuré. Si possible, configurez un « memcache » pour augmenter les performances.

      – L’en-tête HTTP « X-XSS-Protection » n’est pas configurée pour être égale à « 1; mode=block » créant potentiellement un risque relié à la sécurité et à la vie privée. Il est donc recommandé d’ajuster ce paramètre.

      – L’en-tête HTTP « X-Content-Type-Options » n’est pas configurée pour être égale à « nosniff » créant potentiellement un risque relié à la sécurité et à la vie privée. Il est donc recommandé d’ajuster ce paramètre.

      – L’en-tête HTTP « X-Robots-Tag » n’est pas configurée pour être égale à « none » créant potentiellement un risque relié à la sécurité et à la vie privée. Il est donc recommandé d’ajuster ce paramètre.

      – L’en-tête HTTP « X-Frame-Options » n’est pas configurée pour être égale à « SAMEORIGIN » créant potentiellement un risque relié à la sécurité et à la vie privée. Il est donc recommandé d’ajuster ce paramètre.

      – Vous accédez à ce site via HTTP. Nous vous recommandons fortement de configurer votre serveur pour forcer l’utilisation de HTTPS

      Réponse
  • 9 septembre 2015 à 15 h 52 min
    Permalink

    On attribue un espace disque à chaque utilisateur, ce que l’on peut changer quand on veut ou on laisse ‘défaut’ . C’est dans la gestion des utilisateurs. Il suffit de savoir de combien tu disposes encore chez OVH et tu mets ce chiffre avec un coefficient de sécurité.

    Je pense qu’il n’est plus nécessaire de modifier le fichier lib/private/files/storage/local.php ; je l’ai laissé tel qu’il était fourni au départ. Mais, j’ai 250 Go et je n’en n’utilise pas (encore) 10 %

    Réponse
    • 9 septembre 2015 à 15 h 57 min
      Permalink

      Je n’ai pas trouvé Gestion des Utilisateurs mais :
      Gestion de fichiers :
      Taille max. d’envoi 512 Mb (Max. possible :2 GB)
      Ne peut être modifié ici à cause de permissions insuffisantes.

      Comment augmenter ?

      Réponse
  • 9 septembre 2015 à 16 h 19 min
    Permalink

    Les 512 Mo, c’est la taille max. d’un fichier ‘uploadé’. On ne peut pas modifier en mutualisé.
    Si tu veux mettre des plus gros fichiers, il faut le faire avec un client FTP.
    Dans le panneau admin, à droite, gestion des utilisateurs, tu peux mettre un quota par utilisateur. C’est l’espace total disponible par utilisateur.
    Pour les erreurs : php ne semble pas être configuré … celle là, je crois qu’on ne peut rien faire : c’est au niveau de la config php
    pour les autres, j’ai déjà donné quelque part (peut-être sur owncloud.fr ?) mes solutions. Je vais essayer de les retrouver :
    pour forcer https, sans le config.php, tu mets ces 3 lignes
    ‘overwrite.cli.url’ => ‘https://Sousdomaine.domaine’,
    ‘forcessl’ => ‘true’,
    ‘forceSSLforSubdomains’ => true,
    pour le cache mémoire :
    ‘memcache.local’ => ‘\\OC\\Memcache\\ArrayCache’,

    Pour les erreurs de Headers, tu mets en commentaire, dans ton .htaccess :

    ###
    # Add security and privacy related headers
    ### Header set X-Content-Type-Options « nosniff »
    ### Header set X-XSS-Protection « 1; mode=block »
    ### Header set X-Robots-Tag « none »
    ### Header set X-Frame-Options « SAMEORIGIN »
    ### SetEnv modHeadersAvailable true
    ###

    J’ai aussi ajouté une ligne dans un fichier php, mais il faut que je retrouve lequel …

    Réponse
    • 9 septembre 2015 à 16 h 40 min
      Permalink

      Tout marche niquel ! Merci !

      Sauf les deux derniers messages

      – php ne semble pas être configuré de manière à récupérer les valeurs des variables d’environnement. Le test de la commande getenv(« PATH ») retourne seulement une réponse vide.

      – Vous accédez à ce site via HTTP. Nous vous recommandons fortement de configurer votre serveur pour forcer l’utilisation de HTTPS, comme expliqué dans notre aide à la sécurité.

      Réponse
  • 9 septembre 2015 à 16 h 53 min
    Permalink

    Bien. Les erreurs, ce n’est pas grave.
    Pour la première, comme je t’ai dit, on ne peux rien faire.
    Pour la seconde, les solutions qui fonctionnent chez moi ne fonctionnent plus chez les autres : on en a discuté sur un autre forum. Peut-être parce qu’avant, il y avait une option forcer https dans l’admin , que j’ai utilisée et qui laisserait des traces après les mises à jour … en tout cas, j’ai beau fouiller mes tables avec MySqlAdmin, je ne trouve rien. Mystère.

    Réponse
  • 9 septembre 2015 à 16 h 58 min
    Permalink

    Merci l’ami…

    Bonne route et bonnes musiques à toi !

    Ah! Il y a la fête de l’Huma ce week end !

    Réponse
  • 15 septembre 2015 à 12 h 54 min
    Permalink

    Bonjour,
    Tout d’abord, merci pour ce tuto mais aussi à tous ceux qui ont postés ces commentaires qui m’ont fournis une aides précieuse.

    Sur un mutualisé OVH avec la version 8.1.1.
    J’ai une erreur que vous ne rencontrez apparemment pas :

    – Ce serveur ne peut se connecter à internet. Cela signifie que certaines fonctionnalités, telles que le montage de supports de stockage distants, les notifications de mises à jour ou l’installation d’applications tierces ne fonctionneront pas. L’accès aux fichiers à distance, ainsi que les notifications par mail peuvent aussi être indisponibles. Il est recommandé d’activer la connexion internet pour ce serveur si vous souhaitez disposer de l’ensemble des fonctionnalités offertes.

    Mes calendriers et mes dossiers partagés fonctionne correctement mais je n’ai pas accès aux applications supplémentaires par exemple.
    Dans Applications je n’ai que les onglets « Activées » et « Désactivées ».

    Quelqu’un connaît cette avertissement ?

    Réponse
    • 15 septembre 2015 à 13 h 03 min
      Permalink

      Bonjour.
      Il me semble que j’ai déjà obtenu ce message : ça me dit quelque chose.
      À ta place, dans un premier temps, je vérifierai que tous les fichiers et répertoires sont bien présents sur le site : fais une comparaison avec le résultat du « dézippage » en local. (Avec Filezilla c’est « contrôle O »; et que tous les fichiers sont bien accessibles (répertoires en 750) et fichiers en 440, sauf ceux qui doivent être modifiés : 660)
      Est-ce que ta base de données s’est convenablement créée ?
      As-tu installé un OC client sur ton ordi pour vérifier la synchro (et de ce fait, vérifier l’accès Internet) ?

      Réponse
    • 22 septembre 2015 à 16 h 25 min
      Permalink

      il faut mettre la version de PHP à 5.6 dans ton .ovhconfig, et la connexion à internet fonctionne

      Réponse
  • 15 septembre 2015 à 14 h 12 min
    Permalink

    Alors tous les fichiers et répertoires sont présents.
    Par contre je n’ai pas du tout les droits que tu me donnes, moi j’ai les répertoire en 755 et les fichier en 604 ?
    Ma base de données me semble et oui je synchronise bien depuis le client

    Réponse
  • 15 septembre 2015 à 14 h 25 min
    Permalink

    Pour les permissions, c’est bon, du moment qu’ils soient au moins en lecture.
    L’accès à Internet fonctionne puisque tu arrives à synchroniser.
    Le plus fort c’est que j’ai eu cette erreur puisque j’avais posé la même question que toi sur le forum OVH : j’ai résolu mais ne me souviens plus comment !
    Souvent, je ne sais pourquoi, il manque le fichier version.php, mais ça ne donne pas cette erreur.
    Tes adresses sont correctement définies dans le fichier de config ? (trusted domains et datadirectory) et maintenance, check_for_working_htaccess et config_is_read_only mis à false, tandis que installed est mis à true.
    Tu as bien les répertoires apps et 3dparty (je suppose que oui) ?
    Ta version de php est bien la bonne ? (fichier .ovhconfig)
    Sinon, je ne vois rien d’autre pour le moment.

    Réponse
  • 15 septembre 2015 à 14 h 35 min
    Permalink

    Mes adresses sont bonnes :
    Pour « trusted_domains » j’ai « sous-domaine.domain.fr ».
    et pour « datadirectory » j’ai « /home/nom-compte/owncloud/data ».
    maintenance à false.
    J’ai n’ai pas les lignes « check_for_working_htaccess et config_is_read_only ».
    Et « installed » est à « true ».
    Oui tous les répertoires sont présents
    Version php dans .ovhconfig = 5.6

    En tout cas merci quand même

    Réponse
  • 15 septembre 2015 à 14 h 40 min
    Permalink

    Lorsque je suis dans ce genre de situation, je préfère tout effacer et ré-installer : c’est souvent que les erreurs se corrigent d’elles-mêmes et on gagne du temps, et je préfère « dézipper » en local et recopier les fichiers par ftp.
    Tiens nous au courant.

    Réponse
  • 15 septembre 2015 à 14 h 56 min
    Permalink

    Ok, je vais penser à refaire l’installation quand j’aurais un moment et je viendrais donner le résultat.

    Bonne journée

    Réponse
  • 13 octobre 2015 à 19 h 06 min
    Permalink

    Bonjour,

    J’ai installé OwnCloud 8.1.1 sur un mutualisé OVH et depuis hier, sans que je n’aie rien changé, j’ai cette erreur:

    The server encountered an internal error and was unable to complete your request.
    Please contact the server administrator if this error reappears multiple times, please include the technical details below in your report.
    More details can be found in the server log.

    Je n’ai rien dans le log d’erreur, comment puis-je debugger?

    Merci 🙂

    Réponse
    • 13 octobre 2015 à 21 h 26 min
      Permalink

      Je me réponds à moi-même, parce que j’ai trouvé la solution, et il me semble que le souci est arrivé à quelqu’un d’autre ici, je pense que ça pourra aider du monde.

      D’abord, j’ai pas trouvé les logs. Alors j’ai fait le cow-boy et j’ai ouvert index.php pour mettre
      exit($ex);
      juste après
      } catch (Exception $ex) {
      C’est très moche, mais ça a fonctionné. J’ai eu le message d’erreur me disant que ma DB (j’utilise SQLite) était corrompue:
      SQLSTATE[HY000]: General error: 11 database disk image is malformed.

      Donc j’ai téléchargé ma DB qui se trouve dans le dossier data. Ensuite je l’ouvre en ligne de commande et je lance un integrity_check qui me confirme que ma DB est mal formée. Malgré que le fichier soit mal formé, j’arrive quand-même à dumper tout son contenu dans un script rempli d’INSERTs. J’ai fait comme ça:

      $ sqlite3 sqlite.db PRAGMA integrity_check; <– lancement du check d'intégrité
      Error: database disk image is malformed .mode insert .output dump_all.sql .dump .exit <– on quitte sqlite

      Ensuite je crée une nouvelle DB où j'importe ce dump:
      $ sqlite3 fixed.db .read dump_all.sql .exit <– on quite sqlite

      Voilà, j'ai un nouveau fichier fixed.db que je peux remettre à la place du corrompu.

      Tout est ensuite rentré dans l'ordre 🙂

      Réponse
      • 15 octobre 2015 à 9 h 13 min
        Permalink

        Alors ça c’est de la bonne bidouille ! Merci d’avoir partagé l’astuce ici, ça sera utile à plus d’un lecteur je pense 🙂

        Réponse
  • 10 novembre 2015 à 16 h 55 min
    Permalink

    J’ai un soucis avec OC 8.2 … (avant j’avais un gros bug sur OC 7 qui m’a obligé à tout réinstaller en 8.2).

    Tout fonctionnait bien jusqu’à ce que j’ai les messages ci-après, du coup je ne peux plus synchroniser mais je peux accéder via le web :

    1.php ne semble pas être configuré de manière à récupérer les valeurs des variables d’environnement. Le test de la commande getenv(« PATH ») retourne seulement une réponse vide.
    2.La version de PHP utilisée (5.4.45) n’est plus prise en charge par les créateurs de PHP. Nous vous recommandons de mettre à niveau votre installation de PHP pour bénéficier de meilleures performances et des mises à jour de sécurité fournies par PHP.
    3.L’en-tête HTTP « X-XSS-Protection » n’est pas configurée pour être égale à « 1; mode=block » créant potentiellement un risque relié à la sécurité et à la vie privée. Il est donc recommandé d’ajuster ce paramètre.
    4.L’en-tête HTTP « X-Content-Type-Options » n’est pas configurée pour être égale à « nosniff » créant potentiellement un risque relié à la sécurité et à la vie privée. Il est donc recommandé d’ajuster ce paramètre.
    5.L’en-tête HTTP « X-Robots-Tag » n’est pas configurée pour être égale à « none » créant potentiellement un risque relié à la sécurité et à la vie privée. Il est donc recommandé d’ajuster ce paramètre.
    6.L’en-tête HTTP « X-Frame-Options » n’est pas configurée pour être égale à « SAMEORIGIN » créant potentiellement un risque relié à la sécurité et à la vie privée. Il est donc recommandé d’ajuster ce paramètre.
    7.L’en-tête HTTP « Strict-Transport-Security » n’est pas configurée à « 15768000 » secondes. Pour renforcer la sécurité nous recommandons d’activer HSTS comme décrit dans notre guide.

    Globalement rien ne va plus dans mon installation !!!
    Les deux premiers semblent importants et bloquent la synchronisation

    Réponse
    • 10 novembre 2015 à 17 h 12 min
      Permalink

      Bonsoir.
      C’est la dernière fois que j’interviens sur ce forum où il faut s’inscrire à chaque intervention et où l’auteur est aux abonnés absents.
      Rendez-vous sur http://www.owncloud.fr/forum/index.html

      Je ne crois pas que l’on puisse corriger le 1) sur un mutualisé OVH.
      Pour le 2, il faut mettre mettre dans le fichier .ovhconfig (le créer à la racine, [c-a-dire avant www] s’il n’existe pas) :
      app.engine=php
      app.engine.version=5.6
      http.firewall=none
      environment=production

      pour les autres erreurs, qui n’empêchent pas le bon fonctionnement, j’ai déjà expliqué comment j’avais fait (même si ce n’est certainement pas la bonne solution).

      Réponse
      • 10 novembre 2015 à 18 h 03 min
        Permalink

        En effet, je suis passé à coté des explications car je cherchais mon problème de synchronisation. A priori cela n’a rien à voir …
        Désolé !

        Réponse
      • 12 novembre 2015 à 10 h 18 min
        Permalink

        Bonjour,

        plusieurs choses en réaction à ton commentaire.
        Tu confonds « forum » et « tutoriel ». Ces commentaires n’ont pas vocation à remplacer le forum officiel de ownCloud. Je parle de ma propre expérience, en fonction de mes connaissances et compétences, et surtout en fonction de mon temps libre. ET ÇA S’ARRÊTE LÀ.

        Je vous offre effectivement la possibilité de vous entraider, comme sur un « vrai » forum, et je trouve ça super chouette. Je lis la totalité des commentaires postés, quand j’ai une réponse immédiate je le fais, mais j’ai d’autres occupations (ne serait-ce que professionnelles) qui m’empêchent ces derniers temps de passer des heures à chercher pour régler les soucis de chaque visiteur, et surtout d’écrire de nouveaux articles (ce qui m’embête bien plus).

        Alors en effet, si le fait que je ne réponde pas à la moindre question dans l’heure pose problème, je t’invite à aller voir du côté d’une communauté plus active/large. Je ne fais pas office de support externalisé pour ownCloud, je fournis un guide d’installation qui fonctionne, j’aide à l’appliquer, mais je ne peux pas non plus tout résoudre chez tout le monde. À ce compte-là, j’ajoute une page « Tarifs » et je fais ça sous forme de prestation de services, là peut-être que ce temps aura une plus grande valeur que celle que tu sembles lui accorder. Si tu juges aussi sévèrement chaque développeur bénévole qui pour des raisons personnelles stoppe provisoirement son activité, tu vas avoir du mal à trouver ton compte dans les communautés libres.

        Peut-être à bientôt tout de même, qui sait ?

        Maxime

        Réponse
        • 12 novembre 2015 à 10 h 26 min
          Permalink

          Bonjour.

          Désolé pour mon intervention du 10. J’étais de mauvais poil et j’ai répondu un peu vite, sans réfléchir.
          Il n’en reste pas moins vrai que ce tuto ne ma paraît plus à jour. Je t’aurais bien proposé un coup de main pour le remettre à niveau, mais je suis passé sur autre chose et n’ai plus beaucoup de temps.

          Réponse
      • 23 novembre 2015 à 10 h 58 min
        Permalink

        bonjour a tous, j’ai un probleme de mise a jour de la 8.1.4.2 vers la 8.2.1.4 il donne cette erreur

        « La mise à jour a échoué.Unable to move /var/www/owncloud/_oc-upgrade/8.2.1.4/core/resources to /var/www/owncloud/resources »

        alors que j’ai bien mis les permissions

        avais une solution ou une piste merci d’avance 🙂

        Réponse
        • 11 janvier 2016 à 14 h 33 min
          Permalink

          Il faut supprimer le dossier resources et refaire la mise à jour

          Réponse
  • 10 janvier 2016 à 18 h 33 min
    Permalink

    Bonjour,
    Je souhaiterais migrer de SQLite vers MySQL.
    J’ai OC version 8.2.1.
    J’ai trouvé un tuto à base de « OCC », je n’ai jamais compris comment exécuter ces commandes (est-ce seulement possible avec OVH ?)
    Existe t-il une solution qui n’oblige pas à tout réinstaller ?
    Merci

    Réponse
  • 22 février 2016 à 15 h 09 min
    Permalink

    Bonjour,

    Je viens d’installer owncloud 8.2 selon ce tuto. Merci!

    Mais j’ai toujours une page erreur 500 sur le nouveau sous-domaine créé.

    Le log d’erreur OVH me dit :
    [Mon Feb 22 14:54:57 2016] [error] [client 195.81.224.200] [host cloud.audrain-delahaye.name] FastCGI: server « /homez.662/audraindeq/owncloud/index.php » stderr: PHP message: PHP Fatal error: Class ‘OC_Defaults’ not found in /home/audraindeq/owncloud/lib/private/util.php on line 618

    Les lignes 617 et 618 de util.php disent:
    $setup = new \OC\Setup($config, \OC::$server->getIniWrapper(), \OC::$server->getL10N(‘lib’),
    new \OC_Defaults(), \OC::$server->getLogger(), \OC::$server->getSecureRandom());

    Je ne comprends pas pourquoi un élément de Owncloud serait manquant ici ‘OC_Defaults’.

    La version de PHP globale sur OVH est 5.6.

    Merci pour votre aide
    Luc

    Réponse
    • 24 février 2016 à 14 h 00 min
      Permalink

      Bonjour.
      J’ai eu dans le passé des erreurs qui ressemblaient à ça, et je me suis aperçu, en comparant mon répertoire en local avec celui sur OVH, que certains fichiers n’avaient pas été transférés.
      La première chose à faire, à mon avis, est de vérifier que tout a été installé.
      Je suis en 8.2.2 et n’ai pas eu de pb. particulier.
      Bon courage

      Réponse
      • 25 février 2016 à 10 h 09 min
        Permalink

        Bonjour,
        Merci pour votre piste.
        La message que j’ai posté le 22/02 concernait la 8.2.1.
        J’ai récupéré la 8.2.2 et ai refait toute la procédure d’installation.
        J’ai vérifié que le nombre d’éléments au départ et à l’arrivée sont bien identiques après transfert FTP.
        Maintenant, j’ai bien la page d’accueil d’installation!
        Donc ce point est résolu.
        Bien cordialement.

        Réponse
  • 9 mars 2016 à 17 h 18 min
    Permalink

    Bonjour,
    Je viens poster ici mon expérience personnelle face à un problème de synchro entre ownCloud (sur mutu OVH) et Calendrier (ou protocol CalDav) sous Mac OS X El Capitan (10.11.3 pour ma part) qui m’a vraiment donner du fil à retordre pour rester poli.
    Si ça peut servir à quelqu’un…
    Je précise qu’avant de passer sous la dernière mouture de la pomme je n’avais rencontrer aucun soucis pour paramétrer calendrier et contacts, alors sous Lion.

    Problème :
    Vous êtes donc avec votre nouvel OS fraichement installé et vous voudriez reconfigurer Calendrier à votre OC, et là, Bam ! Un message en rouge vous indique « qu’il est impossible de vérifier le nom d’utilisateur ou le mot de passe ».
    Vous avez testé, retesté, vous avez perdu votre latin, cherché dans la console, mais non rien à faire, vous êtes sure de l’adresse de votre serveur ainsi que du nom d’utilisateur et du mot de passe ; et vous avez raison. C’est un bug connu d’el capitan.

    Solution :
    La solution va se trouver dans le fichier .htaccess du dossier /owncloud généré par l’install.
    Inspiré par cet article : https://forum.owncloud.org/viewtopic.php?t=32655
    j’ai ajouté à la fin de mon fichier ces deux lignes :
    Redirect 301 /.well-known/carddav /remote.php/carddav
    Redirect 301 /.well-known/caldav /remote.php/caldav

    Comme ceci :
    =======================

    ModPagespeed Off

    Redirect 301 /.well-known/carddav /remote.php/carddav
    Redirect 301 /.well-known/caldav /remote.php/caldav

    ErrorDocument 403 /core/templates/403.php
    ErrorDocument 404 /core/templates/404.php
    ========================

    Puis j’ai dans un 1er temps commenter ces deux autres ligne :
    =====================

    RewriteEngine on
    RewriteRule .* – [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
    RewriteRule ^\.well-known/host-meta /public.php?service=host-meta [QSA,L]
    RewriteRule ^\.well-known/host-meta\.json /public.php?service=host-meta-json [QSA,L]
    # RewriteRule ^\.well-known/carddav /remote.php/carddav/ [R=301,L]
    # RewriteRule ^\.well-known/caldav /remote.php/caldav/ [R=301,L]
    RewriteRule ^apps/calendar/caldav\.php remote.php/caldav/ [QSA,L]
    RewriteRule ^apps/contacts/carddav\.php remote.php/carddav/ [QSA,L]
    RewriteRule ^remote/(.*) remote.php [QSA,L]
    RewriteRule ^(build|tests|config|lib|3rdparty|templates)/.* – [R=404,L]
    RewriteRule ^(\.|autotest|occ|issue|indie|db_|console).* – [R=404,L]

    ======================

    Pour finalement conclure que si l’app Calendrier sous El Capitan ne savait pas lire les règles de réécriture du mod_rewrite.c de PHP qui se trouvent entre deux balises , il n’était pas nécessaire de les commenter car il fallait penser aux autres. Ce que j’ai fais (de toute façon ds les deux cas cela fonctionne)

    Pour l’ajout du compte calendrier vous procédez comme d’habitude :
    – Ajouter un compte CalDAV
    – Type de compte : Avancé
    – Nom d’utilisateur
    – Mdp
    – Adresse du du serveur : sousDomaine.monDomaine.tld (dans mon cas, ici c’est selon votre config)
    – Chemin du serveur : /remote.php/caldav/principals/utilisateur/ (Adresse CalDAV pour iOS/OS X … hein ! 🙂
    – Port 443, cochez utilisez SSL

    Enjoy

    PS : Avant de trouver cette solution j’ai pris le risque d’utiliser la MAJ automatique d’OC (de 8.1.3 à 8.2.2) et tout c’est bien passé si ça peut répondre à quelques postes vu plus haut. Il a quand même fallu régler à nouveau les msg d’erreurs en en-tête de la partie admin dont les procédures sont très bien expliquées dans différents post de ce tuto.

    Réponse
  • 14 mars 2016 à 11 h 57 min
    Permalink

    Bonjour à tous,
    Est-ce que certains d’entre vous ont tenté la mise à jour vers owncloud 9 ?
    Perso, une fois les fichiers envoyés via FTP, j’obtiens une page blanche lorsque j’accède à mon sous-domaine qui héberge Owncloud. J’ai essayé de changer quelques réglages (changer la version php entre autres, désinstaller quelques plugins puis tous les plugins,…) sans succès. Du coup, j’ai tenté de réinstaller owncloud 8.2.2. Cela a fonctionné sans souci et cela fonctionne comme avant.
    Si vous avez réussi à installer owncloud 9 sur un serveur mutu d’OVH, votre retour d’expérience m’intéresse !

    Réponse
    • 14 mars 2016 à 14 h 41 min
      Permalink

      J’ai plus ou moins réussi, au prix de 4 ou 5 installations foireuses… Erreurs 500 à la pelle, tout ça…

      Le mieux est à mon sens de l’installer avec le fichier setup-owncloud.php (qui va foirer à la fin, mais pas grave) et de finir l’installation « normalement » en retournant sur l’index. Il faut migrer les données ensuite, c’est long, chiant, mais ça passe.

      Pour ma part je vais le tester « en profondeur » avant de tout péter, des fois que. Je garde mes données sur la 8.2.3 pour le moment 😉

      Réponse
  • 14 mars 2016 à 15 h 05 min
    Permalink

    Je voulais essayer, mais, copte tenu de vos commentaires, je vais attendre un peu …

    Réponse
    • 14 mars 2016 à 22 h 13 min
      Permalink

      Finalement, j’ai retenté le coup ce soir.
      J’ai fait la mise à jour 8.2.2 > 8.2.3. J’ai obtenu là aussi une page blanche.
      J’ai tout viré une fois de plus (sauf data et config) et tout re-uploadé (fichiers de la version 8.2.3). Et la mise à jour s’est passée nickel ce coup-ci.
      Et dans la foulée, j’ai tenté le passage 8.2.3 > 9.0.0. Ce coup-ci pas de page blanche, j’ai bien eu la page m’invitant à faire la mise à jour. La mise à jour a échouée à cause d’une erreur. J’ai relancé la mise à jour une 2nde fois, et elle s’est bien déroulée ce coup-ci.
      En gros, je n’ai rien changé aux paramètres serveurs mais ça a fonctionné. Peut-être que des fichiers étaient corrompus seraient à l’origine de la page blanche ?
      Je ne vais chercher plus loin, ça marche c’est l’essentiel. 🙂
      Bon courage à vous.
      Sinon pour info, les quelques plugins que j’utilise marchent nickel avec la v9 (calendar+, tasks+, contacts+), moyennant la petite manip pour changer le n° de version maxi

      Réponse
      • 15 mars 2016 à 9 h 21 min
        Permalink

        Ça a quand même l’air un peu aléatoire tout ça 😀

        Pas de soucis de synchro, pas de BDD corrompue si tu uploades (par le client) des fichiers de plus de 10Mo ?

        Réponse
  • 17 mars 2016 à 9 h 34 min
    Permalink

    Je test actuellement ownCloud sur mon mutualisé OVH et j’ai quelques questions.

    Est-ce que c’est une bonne idée d’utiliser le SSL du mutu car j’ai ces messages ?
    – This page is insecure (broken HTTPS).
    – Certificat SHA-1 (obsolète)
    – Des problèmes relatifs à la chaîne de certificats du site ont été détectés (net::ERR_CERT_COMMON_NAME_INVALID).
    Mais la connexion a tout de même l’air d’être encryptée
    – All resources on this page are served securely.

    J’ai aussi lu que pour utiliser le SSL du mutu il fallait passer par une URL du style « https://sslxxx.ovh.net/~LoginFTP/owncloud/ » mais je l’utilise avec mon sous domaine est ça a l’air de passer. Est-ce que ça peut poser problème ?

    Merci.

    Réponse
  • 17 mars 2016 à 14 h 08 min
    Permalink

    J’ai aussi ces erreurs (owncloud 8.2.3) :

    – Votre serveur web n’est pas correctement configuré pour la synchronisation de fichiers : l’interface WebDAV semble ne pas fonctionner.
    Alors que j’ai bien ajouté ‘check_for_working_webdav’ => false,

    – L’en-tête HTTP « X-XSS-Protection » n’est pas configurée pour être égale à « 1; mode=block » créant potentiellement un risque relié à la sécurité et à la vie privée. Il est donc recommandé d’ajuster ce paramètre.

    – L’en-tête HTTP « X-Content-Type-Options » n’est pas configurée pour être égale à « nosniff » créant potentiellement un risque relié à la sécurité et à la vie privée. Il est donc recommandé d’ajuster ce paramètre.

    – L’en-tête HTTP « X-Robots-Tag » n’est pas configurée pour être égale à « none » créant potentiellement un risque relié à la sécurité et à la vie privée. Il est donc recommandé d’ajuster ce paramètre.

    – L’en-tête HTTP « X-Frame-Options » n’est pas configurée pour être égale à « SAMEORIGIN » créant potentiellement un risque relié à la sécurité et à la vie privée. Il est donc recommandé d’ajuster ce paramètre.

    – L’en-tête HTTP « Strict-Transport-Security » n’est pas configurée à « 15768000 » secondes. Pour renforcer la sécurité nous recommandons d’activer HSTS comme décrit dans notre Guide pour le renforcement et la sécurité.

    – Aucun cache de la mémoire n’est configuré. Si possible, configurez un « memcache » pour augmenter les performances. Pour plus d’information consultez la documentation.

    Si vous avez des infos je prends 😉

    Réponse
    • 18 mars 2016 à 11 h 06 min
      Permalink

      A propos du WebDAV cela ne fonctionne pas 🙁

      Réponse
    • 18 mars 2016 à 11 h 54 min
      Permalink

      Pour le cache, j’ai mis :
      ‘memcache.local’ => ‘\\OC\\Memcache\\ArrayCache’,
      dans le fichier de config.
      J’avais essayé d’autres valeurs mais je n’ai trouvé que celle-ci qui fonctionne (la documentation est des plus succincte !)
      Dans le .htaccess, j’ai mis en commentaire comme suit :
      ##
      ## # Add security and privacy related headers
      ## Header set X-Content-Type-Options « nosniff »
      ## Header set X-XSS-Protection « 1; mode=block »
      ## Header set X-Robots-Tag « none »
      ## Header set X-Frame-Options « SAMEORIGIN »
      ## SetEnv modHeadersAvailable true
      ##

      Réponse
      • 18 mars 2016 à 14 h 09 min
        Permalink

        Merci ça fait disparaître quelques messages d’erreurs. Par contre niveau sécurité je sais pas ce que ça vaut 😉

        Réponse
      • 29 mars 2016 à 11 h 10 min
        Permalink

        Effectivement, c’est la manière forte 😀

        Bon et puis niveau sécurité, pour le moment, ça ne change rien puisque OVH ne supporte pas les instructions demandées dans ce .htaccess (d’où les erreurs). À revérifier de temps en temps ? 🙂

        Réponse
  • 18 mars 2016 à 11 h 50 min
    Permalink

    Décidément, chaque nouvelle version de owncloud apporte son lot de problèmes.
    J’ai essayé, en local, une nouvelle installation complète 9.0 : pas d’accès aux fichiers contenus dans les répertoires sous data.
    Mon fichier error.log (apache) contient une multitude de
    « AH01630: client denied by server configuration: »
    J’ai essayé une première fois avec l’installation par défaut (avec sqlite3); comme ça ne fonctionnait pas, j’ai essayé avec mysql : pas mieux. Bref, tant que ça ne fonctionne pas en local, je n’essaierai pas sur le serveur.

    Réponse
    • 18 mars 2016 à 14 h 10 min
      Permalink

      Pour moi sur mon OVH mutu ownCloud 9 ne fonctionne pas. Je peux installer des apps comme les contacts mais impossible d’ajouter quoi que ce soit (fichier, contact, événement)…

      Réponse
      • 29 mars 2016 à 13 h 47 min
        Permalink

        J’ai corrigé ça en désactivant le pare-feu applicatif (mod_security)

        Réponse
  • 18 mars 2016 à 13 h 23 min
    Permalink

    En y passant beaucoup (trop) de temps, on fini par y arriver.
    J’ai mis en commentaire la ligne SetEnv front_controller_active true dans le .htaccess et ça fonctionne enfin !
    Je n’ai plus que l’avertissement :
     » Vous accédez à ce site via HTTP. Nous vous recommandons fortement de configurer votre serveur pour forcer l’utilisation de HTTPS, comme expliqué dans notre Guide pour le renforcement et la sécurité. »
    qui est normal.

    Réponse
    • 29 mars 2016 à 11 h 12 min
      Permalink

      Pour la redirection HTTP(S), tu peux ajouter ces deux lignes dans le .htaccess (dans le bloc avec les autres règles, à la suite) :

      1
      2
      RewriteCond %{HTTPS} off
      RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

      Ça forcera HTTPS et fera (de fait) disparaître le message… Attention au certificat mutualisé qui provoque un avertissement. 😕

      Réponse
      • 29 mars 2016 à 12 h 04 min
        Permalink

        J’ai franchi le pas et installé la 9.0 sur OVH.
        Je n’ai pas eu besoin de mettre ces 2 lignes sur mon serveur OVH et il est toujours automatiquement en https depuis 8.0, sans que je sache exactement pourquoi. Dans mon fichier de config, j’ai ‘forcessl’ => ‘true’, mais d’autres personnes ont dit que ça ne changeait rien pour elles.
        Ce que je disais, c’est pour ma config locale : j’ai toujours l’avertissement, mais en local, me m’en fiche.
        À signaler un (tout petit) bogue à corriger pour l’aide : un des fichiers php (je ne sais plus lequel) met l’adresse à /server/8.0/go.php au lieu de /server/9.0/go.php.
        Sur le serveur, je n’ai plus que le message concernant getenv(« PATH ») , mais je ne crois pas qu’on puisse faire quelque chose.

        Réponse
      • 29 mars 2016 à 13 h 15 min
        Permalink

        Salut à tous,

        Maxime, ça ne serait pas possible de faire un petit « edit » sur cet article pour ajouter les petites manips évoquées dans les commentaires de ce post ?

        Après plusieurs jours d’usage normal, je peux affirmer que j’ai une version 9.0 qui tourne bien.

        Voici un résumé des réglages et ajustements que j’ai effectué pour que tout roule (ne concerne pas spécifiquement la v9) :
        – PHP 5.6
        – Depuis plusieurs versions, plus d’effectuer les modifs 1 et 2 de ce tuto
        – Dans .htaccess :
        (contre le message http au lieu de https)
        RewriteCond %{HTTPS} off
        RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
        (contre les messages concernant les en-têtes HTTP)
        mettre en commentaire les lignes suivantes :
        ###
        # Add security and privacy related headers
        ### Header set X-Content-Type-Options « nosniff »
        ### Header set X-XSS-Protection « 1; mode=block »
        ### Header set X-Robots-Tag « none »
        ### Header set X-Frame-Options « SAMEORIGIN »
        ### SetEnv modHeadersAvailable true
        ###
        – Dans lib/private/response.php :
        (Contre le message http au lieu de htpps)
        après la ligne :
        header(‘X-Robots-Tag: none’); // https://developers.google.com/webmasters/control-crawl-index/docs/robots_meta_tag
        ajouter :
        header(‘Strict-Transport-Security: 15768000’);
        – Dans config.php
        (contre le message de problème de mémoire cache)
        ‘memcache.local’ => ‘\\\\OC\\\\Memcache\\\\ArrayCache’

        J’ai rencontré des difficultés à recevoir le
        – dans le manager OVH,
        ajouter le cron.php de Owncloud dans les routines CRON
        Si les notifications mail ne fonctionnent pas après cet config, faire la vérif suivante :
        – dans PHPmyADMIN,
        si comme moi les lignes EmailNotification et ExpireActivities ont disparu de la table oc_jobs
        les recréer via :
        insert into oc_jobs (class,argument) values (‘OCA\\Activity\\BackgroundJob\\EmailNotification’,’null’);
        insert into oc_jobs (class,argument) values (‘OCA\\Activity\\BackgroundJob\\ExpireActivities’,’null’);

        A ma connaissance, pas de solution connue contre le message concernant getenv(« path »)

        a+

        Réponse
        • 30 mars 2016 à 16 h 16 min
          Permalink

          Bien, cette mise à jour récapitulative. Merci.
          Pourrais-tu expliquer un peu mieux l’histoire du cron ? Je l’ai ajouté dans le manager OVH mais je n’ai pas bien compris à quoi ça servait.

          Réponse
        • 20 avril 2016 à 8 h 40 min
          Permalink

          Pour les headers, plutôt que de les commenter, autant ajouter un « always » avant le set. Ça passe tout autant et ça me paraît moins « douteux » 😀
          Pour le HSTS, même topo, sans modifier le fichier php dont tu parles, directement dans le .htaccess :

          1
          Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"

          Pour le cache pareil, ça fonctionne, mais sans tous ces \\ :

          1
          'memcache.local' => '\\OC\\Memcache\\ArrayCache',

          Pour le retour de l’espace, je regarde en ce moment, même si (sauf certains cas précis) ça ne porte pas trop à préjudice… On va y arriver ! 🙂

          Je ferai sans doute un récapitulatif une fois tout ça au poil !

          Réponse
          • 20 avril 2016 à 12 h 45 min
            Permalink

            Bonjour et merci, Maxime.
            Je ne connaissais pas cette instruction « Header always set ». Je mets ça tout de suite dans mon .htaccess.

  • 29 mars 2016 à 12 h 30 min
    Permalink

    J’ai donc bien installé chez OVH, en mutu, la version 9.0 et j’ai essayé de remplacer mon agenda Google, que j’ai récupéré.
    Dans mon ‘courrielleur’ Thunderbird, en local, avec l’option Lightning, j’ai essayé de synchroniser cet agenda (adresse : https://mon.domaine.fr/remote.php/dav/ )
    et là, rien ne se passe après avoir entré mon mot de passe. À côté du nom de l’agenda, au lieu d’avoir l’icône représentant un cadenas, j’ai une icône avec un point d’exclamation . Quelqu’un aurait une idée ?

    Réponse
        • 30 mars 2016 à 16 h 09 min
          Permalink

          Je n’ai pas essayé, mais c’est curieux : s’il y a plusieurs utilisateurs avec plusieurs agendas différents, comment il peut s’y retrouver ?
          Pour installer DavDroid, il faut installer un agenda en plus, ou il se suffit à lui même ?
          J’ai essayé (mais en vitesse) esayDav, qui est gratuit, mais je ne comprends pas comment ça fonctionne (et en plus, c’est en allemand).

          Pour le moment (mais je n’ai pas beaucoup de temps à y consacrer) ça fonctionne impec. sur mon PC, avec Thunderbird et Lightning

          Réponse
          • 31 mars 2016 à 13 h 32 min
            Permalink

            Je pense qu’il s’y retrouve avec ton login. L’agenda par défaut d’Android fonctionne parfaitement et DavDroid se configure en 2 mn.

  • 1 avril 2016 à 7 h 25 min
    Permalink

    Bonjour,
    Merci pour ce tuto qui m’a permis de découvrir Owncloud sur un mutualisé d’OVH.
    J’ai installé la version 9.0 et je rencontre un problème avec filelink de thunderbird :
    L’espace disponible n’est pas renvoyé dans cette extension, malgré la modification du fichier /lib/private/files/storage/local.php
    Je pense donc qu’il y a une autre modif à faire. Si vous avez une idée…
    J’ai par contre pas mal de problème avec le client Owncloud pour Windows, qui a beaucoup de mal à synchroniser les gros fichiers (ma connexion ADSL est assez mauvaise et je me retrouve avec beaucoup de fichiers en liste noire).

    Réponse
    • 1 avril 2016 à 11 h 34 min
      Permalink

      Voir ci dessus :
      – Depuis plusieurs versions, plus d’effectuer les modifs 1 et 2 de ce tuto

      Réponse
      • 4 avril 2016 à 13 h 03 min
        Permalink

        Bonjour,
        Je suis d’accord que tout fonctionne sans faire les modifs 1 et 2 de ce tuto. Cependant, comme aucune valeur concernant l’espace disque disponible n’est retournée avec la version Owncloud 9.0, l’extension Owncloud pour thunderbird ne fonctionne plus. J’imagine que cela sera aussi le cas pour d’autres applications qui ont besoin de vérifier l’espace disponible pour s’exécuter.

        Réponse
    • 12 avril 2016 à 11 h 10 min
      Permalink

      Si tu as l’erreur 2006 MySql has gone away, tu peux modifier le fichier owncloud.cfg sur ton poste client, et dans la rubrique [General], ajouter la ligne
      chunkSize=2000000
      Il va ainsi découper chaque fichier en morceau de 2mo (environ).
      Tu peux modifier cette valeur selon ta connexion. De mon côté, en WIFI, c’est le maximum que j’ai pu mettre et je n’ai quasi plus d’erreurs.
      A savoir que ça ralentit la synchro apparemment
      https://github.com/owncloud/client/issues/4354

      Réponse
  • Ping : [Tuto] ownCloud 9 sur un mutualisé OVH - Open-Freax

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *