[Tuto] ownCloud 9 / 9.1 / NextCloud 10 sur un mutualisé OVH

ownCloud 9 est sorti depuis quelques temps, la v9.0.1 est dispo à la date à laquelle je rédige… Tout va bien dans le meilleur des mondes. Ou pas.

Concrètement, la stack web des mutualisés OVH est toujours aussi daubée, sinon davantage. J’ai fait remonter un certain nombre de soucis, par vagues, entre il y a 1 an et demie et il y a 2-3 mois, la réponse étant toujours la même : « ça arrive ». J’en suis à ma 14e semelle usée à taper du pied devant mes logs d’erreurs.

 

Bref, voyons ce qu’on peut faire cette nouvelle mouture d’ownCloud !

 

Pré-requis

On ne va pas refaire le monde, je vous conseille évidemment d’utiliser au moins PHP 5.6, voire la version 7. Pour ça, passez par le fichier .ovhconfig ou, plus simple, par votre Manager OVH. Attention, passer « comme ça » à PHP7 risque de « casser » quelques-unes de vos applications (par exemple, mon Pydio n’a pas apprécié la blague). Mais en 5.6, tout va bien pour le moment !

Je vous conseille également d’utiliser MySQL et pas SQLite, si vous avez pas mal de fichiers et/ou de comptes, sinon, bonjour les dégâts et la base corrompue à mort (testé et désapprouvé).

Oh, et de mon côté, après de multiples tentatives de mise à jour depuis la 8.2.3 (et autant d’échecs), je me suis résigné à faire une installation propre. À vous de voir, mais faites une sauvegarde avant de tenter ! 😉

 

As usual, il vous faut donc simplement un client FTP et l’archive d’installation officielle. Vous pouvez aussi utiliser le script d’installation pour mutualisés, mais en essayant j’ai eu plusieurs erreurs bizarres, donc je préfère faire sans, même si c’est un poil plus long…

 

Capture du 2016-04-20 11:04:21

 

Étape 1 : installation

Dorénavant, plus de modifications de .htaccess pour pouvoir installer quoi que ce soit : téléversez l’archive extraite via FileZilla (par exemple), pointez votre navigateur web vers la page d’installation, et suivez les instructions. C’est tout bon ! Vous pouvez vous y connecter et activer d’autres applications fournies (Agenda, Contacts, Documents…), tout ça tout ça.

Sauf que… vous accédez probablement à ownCloud via HTTP. C’est mal. Et que si vous allez dans la partie Administration… C’est blindé d’erreurs de partout. Ah ça oui c’est utilisable, mais crade. Encore une fois, parce que le serveur web OVH est mal configuré et ne supporte pas les instructions demandées par ownCloud.

 

Étape 2 : se débarrasser des erreurs

Étape 2a : les headers

Pour cela, ouvrez le fichier .htaccess et repérez le pavé qui cause des headers.

Modifiez chaque ligne commençant par Header set en Header always set, et ajoutez la ligne au bloc en question :

Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"

 

Étape 2b : forcer HTTPS

Toujours dans le .htaccess, dans le bloc qui parle des RewriteRules, ajoutez :

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

Ces lignes indiquent que si on accède au sous-domaine concerné via HTTP seulement, alors on renvoie un code 301 (redirection) et on redirige sur la même URL, mais avec un HTTPS devant. Voilà. Erreur de certificat invalide comme depuis toujours, mais on vit avec…

 

Étape 2c : activer le cache

Modifiez le fichier config/config.php et ajoutez la ligne :

'memcache.local' => '\\OC\\Memcache\\ArrayCache',

Puis rechargez la page d’administration, et c’est tout bon.

 

Étape 2e : la vérification de code

Puisque nous avons modifié des fichiers propres à ownCloud, et que depuis quelques temps maintenant un mécanisme vérifie que l’empreinte du fichier en place correspond bien à l’empreinte du fichier fourni par ownCloud, il paraît logique que ce mécanisme puisse détecter nos modifications et nous en avertir (c’est le but, à la base). Deux options : vivre avec ce bandeau jaune (visible seulement par les administrateurs), ou désactiver la vérification (pas super recommandé, mais ça dépanne).

Dans ce 2e cas, il vous faut ouvrir le fichier config/config.php et ajouter : 'integrity.check.disabled' => true puis relancer la vérification d’intégrité. Le message va disparaître.

 

Étapes restantes…

Restent 2 « soucis » : une erreur concernant la configuration de php-fpm, côté serveur donc, pour laquelle je ne sais pas s’il est possible de faire quelque chose sans passer par OVH. Enfin, l’espace disponible n’est pas renvoyé, même avec ma manip’ « habituelle » : il faut creuser là-dessus ! Rien de bloquant pour le moment, sauf certaines extensions comme celle pour les « gros fichiers » de Thunderbird qui vérifient l’espace disponible… et illimité ne lui convient pas 😛

Si vous avez des idées, je prends ! Au passage, merci aux lecteurs qui ont filé un coup de main pour dépatouiller ça depuis quelques mois, via les commentaires de l’article pour ownCloud 7/8 <3

 

 

 

Étape 3 : installer le client sans péter sa synchro

Ça parait couillon dit comme ça, hein. Et pourtant…

Techniquement, l’équipe de développement d’ownCloud a décidé que les gros fichiers devaient être découpés en morceaux de 10Mo. Ça se défend, je ne le remet pas en cause. Simplement, sur nos connexion ADSL classiques, ça prend un peu de temps à envoyer, des bouts de 10Mo. Conséquence : le serveur MySQL d’OVH, qui attend les infos sur le fichier tout au long du process, finit par se lasser et fermer la connexion… entraînant l’arrêt de la synchronisation dudit fichier, et une erreur type « MySQL has gone away ». Encore une fois, « on y travaille »… ou pas ? J’ai ces erreurs depuis (au moins) l’été dernier.

J’ai donc décidé, pour régler le problème côté client, de découper mes « gros » fichiers en morceaux de 1Mo. Plus petit, donc plus rapide à envoyer, donc de multiples connexions à MySQL mais d’une durée plus courte. Et ça passe.

 

Pour ça, sous Linux, c’est simple, ajoutez à vos variables d’environnement la suivante : export OWNCLOUD_CHUNK_SIZE=1000000 . Concrètement, vous pouvez soit l’ajouter à votre propre fichier .profile (situé à la racine de votre dossier personnel, ce qui n’affectera que votre utilisateur), soit la propager à tout le système en l’ajoutant au fichier /etc/profile (il vous faudra les droits superutilisateur, dans ce cas).

 

Redémarrez, installez le client en suivant les instructions officielles, connectez votre compte et laissez la magie faire son boulot ! 😀

140 commentaires sur “[Tuto] ownCloud 9 / 9.1 / NextCloud 10 sur un mutualisé OVH

  • 20 avril 2016 à 13 h 13 min
    Permalink

    Génial, Je cherchais justement comment virer toutes ces erreurs, et Hop le Tuto tout juste créé.
    Merci beaucoup pour ces explications toujours aussi claires !

    Réponse
  • 20 avril 2016 à 15 h 12 min
    Permalink

    Coucou,

    Encore un chouette tuto !

    Une petite précision concernant les variables d’environnement qui sont aussi disponibles sous OS X et sous Windows.

    OS X: C’est la même commande que celle indiquée dans le tuto, puis vérifier dans le fichier de log situé: « /Applications/owncloud.app/Contents/MacOS/owncloud »

    Windows: Panneau de configuration > Système > Paramètres système avancés

    Puis créer une nouvelle variable soit pour l’utilisateur en cours, soit pour l’entièreté du système:
    Nom de la variable: OWNCLOUD_CHUNK_SIZE
    Valeur de la variable: 1000000

    Et pour ceux qui se posent la question, c’est une variable d’environnement _client_ donc un « SetEnv OWNCLOUD_CHUNK_SIZE=5MB » dans un .htaccess ne sert à rien (le fichier est découpé PAR le système avant envoi, et non pas à la réception sur le serveur).

    Mes deux centimes. o/

    Réponse
  • 20 avril 2016 à 16 h 45 min
    Permalink

    J’avais pas le courage de chercher une solution et je tombe ici: parfait!

    une coquille :
    ‘memcache.local’ => ‘\\OC\\Memcache\\ArrayCache’,
    ‘memcache.local’ => ‘\\OC\\Memcache\\ArrayCache’,

    Par contre, j’ai toujours: « 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. »

    et un pb avec la vérification d’un certain nb de fichiers: « Des fichiers n’ont pas passé la vérification d’intégrité. Consultez la documentation pour avoir plus d’informations sur comment résoudre ce problème. (Liste des fichiers non valides… / Relancer…) » depuis l’installation de ownCloud 9.0.1 (stable)

    Réponse
    • 21 avril 2016 à 8 h 50 min
      Permalink

      Hello,

      la coquille n’en est pas (vraiment) une, c’est juste l’échappement des caractères qui merdouillait, c’est réglé ! Merci à toi 🙂

      Pour ton en-tête, c’est étrange, tu as ajouté les « always » partout ? Celle-ci figure bien dans la liste ?

      Pour les fichiers « pas intègres », j’ai le souci aussi, et apparemment c’est le fichier de contrôle (qui contient les sommes de référence) qui n’a pas été mis à jour avant la publication. Du coup, à mon sens rien d’anormal, d’autant que ce n’est pas la première fois que ça arrive…
      Et d’autant plus que puisque je vous fait modifier des fichiers dans ce tutoriel, le message apparaîtra forcément. Mais il est possible d’exclure manuellement des fichiers !

      Réponse
  • 20 avril 2016 à 19 h 52 min
    Permalink

    Bonjour,

    « Concrètement, la stack web des mutualisés OVH est toujours aussi daubée, sinon davantage. »

    Tu aurais des détails stp ?

    Réponse
    • 20 avril 2016 à 21 h 49 min
      Permalink

      Salut Guillaume,

      Boh, libs pas à jour qui causent parfois des soucis (genre SSL fut un temps, gzip plus récemment qui créée des archives corrompues dans ownCloud ou Pydio), lenteurs, temps d’exécution des scripts et requêtes SQL revu à la baisse (d’où le chunk_size faible alors que pas nécessaire auparavant), php-fpm mal configuré ou trop restrictif, fonctions PHP bridées (genre free_space qui ne renvoie rien), directives dans les htaccess pas toujours prises en compte (HSTS et tout ça), pas de ssh (chiant pour certaines apps) sur l’offre perso (alors que clairement du FTP « classique en clair » c’est à éviter), le manager qui a longtemps déconné, les stats et logs accessibles 1 fois sur 2… Ah c’est pas cher mais quand on pousse un peu l’usage sur ce à quoi on a droit ou sur ce qu’on devrait attendre d’un poids lourd du marché, on regrette d’avoir gratté et les réponses apportées ne sont pas à la hauteur. La liste peut sûrement être allongée…
      EDIT : je me souviens que pas mal d’applis en PHP plantent dès l’installation pour cause de « restrict API » de Zend OP Cache, ça aussi c’est chiant… et relativement récent (genre depuis cet été).

      Je sais de source semi officielle mais pas publique que OVH a d’autres chats à fouetter en ce moment, mais tout de même…
      J’aime bien OVH, depuis des années, sur l’ADSL ils sont franchement bien, sur plein de choses en fait, mais les mutualisés deviennent mauvais. Sont-ils vus comme une simple porte d’entrée « attrape couillon » vers des offres plus chères voire des dédiés ? Je ne sais pas… Mais je commence à être frustré, voire déçu.

      Tu n’es pas de cet avis, si tu as un mutu chez OVH ? C’est une vraie question, pas simplement de la rhétorique 😉

      Réponse
      • 21 avril 2016 à 9 h 11 min
        Permalink

        Bonjour,

        En fait je suis admin sys et je travaille sur les infrastructures du mutu OVH 🙂
        Tes remarques sont très intéressantes, j’en prends note et je vais voir ce que je peux faire ! N’hésite pas à partager ton expérience et à nous donner plus de détails sur le forum par exemple : https://forum.ovh.com/forumdisplay.php/8-H%C3%A9bergements-Web

        Moi et mon équipe le surveillons de près, et nous faisons de notre mieux pour répondre aux demandes pour peu quelles soient constructives 🙂

        Réponse
  • 21 avril 2016 à 8 h 25 min
    Permalink

    Merci pour ce tuto bien détaillé et fort intéressant. J’allais vous demander quelle version utilisée pour Pph pour que ça fonctionne, et j’ai relu un peu le début et j’ai vu la réponse. Nous n’avons pas encore essayé mais nous n’allons pas tarder à nous y mettre.

    Réponse
  • 21 avril 2016 à 14 h 13 min
    Permalink

    Merci pour ce tuto une nouvelle fois très claire ! Et si en plus OVH s’en mêle pour régler les pbms PHP-fpm et autres… :p

    Sinon, concernant la 2ème solution de l’étape 2e :
    J’ai ça qui apparait dans dans ton paragraphe : « ‘integrity.check.disabled’ => true » (qui forcement, si comme moi, on fait un copier/coller de grosse faignasse ne fonctionne pas) au lieu de :
    ‘integrity.check.disabled’ => true,

    Réponse
    • 21 avril 2016 à 16 h 42 min
      Permalink

      Merci pour la coquille, je vais la corriger… Et relire tous les bouts de code, souci d’échappement des caractères. J’suis parfois flemmard aussi 😛

      Réponse
      • 12 mai 2016 à 19 h 08 min
        Permalink

        Un autre souci dans le code : les tags  et sont mal placés pour les RewriteCond suivants :
        RewriteCond %{HTTPS} off
        RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

        Tu peux aussi préciser qu’il faut les mettre avant les autres, pas à la fin, sinon ça ne marche pas.

        Réponse
        • 13 mai 2016 à 9 h 48 min
          Permalink

          Oui, merci ! C’est en éditant pour l’échappement que j’ai zappé ces 2 tags… Corrigé 🙂

          Réponse
  • 21 avril 2016 à 16 h 29 min
    Permalink

    (re)Bonjour Maxime,

    J’ai pris un peu de temps aujourd’hui pour me pencher sur ce que tu dis 🙂

    Concernant les problèmes soulevés par l’installation d’OwnCloud, je vais m’en mettre un en test pour pouvoir creuser.

    Les problèmes de certificats SSL devraient être résolus d’ici peu, aux dernières nouvelles les certificats SSL sont toujours en cours de génération. Comme on en à près d’1,5 millions à faire, ça prend un peu de temps. C’est aussi l’occasion pour nous de mettre en production des nouveaux systèmes pour supporter tous ces certificats. Et vu les volumes avec lesquels on travaille, c’est normal qu’on rencontre parfois quelques difficultés avec certains clients. Nous avons tous hâte de proposer du Let’s Encrypt à tous nos clients mutu en tout cas !

    Pour la fonction disk_free_space(), le problème vient du fait que l’environnement d’exécution côté client est (malheureusement) toujours en 32 bits. La fonction cherche sans doute à retourner l’espace disque libre du « filerz » sur lequel tu es, et cette valeur est trop grande pour PHP… Le contournement qui était proposé par tes lecteurs ne peut plus fonctionner car la SoAPI a été fermée cette semaine. Il faudrait adapter cette solution à la nouvelle API OVH. Pour trouver de l’aide je te conseille plutôt le forum.

    Pour les « MySQL has gone away », je ferai le test quand j’aurai terminé d’installer un OwnCloud, et je reviendrai par ici 🙂

    Ensuite, les lib pas à jour, notamment gzip et openssl. Nous sommes justement en train de déployer les nouvelles version des environnements d’exécution pour nos client. On se base sur Debian 8.4 Jessie donc les lib sont aux versions correspondantes à celles présentes dans les dépôts Debian. La configuration de cet environnement passe par le .ovhconfig ou il suffit d’utiliser quelque chose comme « container.image=stable » pour passer sur la version courante stable. Plus d’infos sur le forum : https://forum.ovh.com/showthread.php/109560-Changer-l-environnement-d-ex%C3%A9cution-de-vos-h%C3%A9bergements-web-%28drupal8-TLS1-2%29

    À propos de SSH sur les offres pro, la décision ne m’appartient pas, mais là encore tu peux en parler sur le forum.

    Quels problèmes rencontres-tu avec l’accès aux logs ? On parle bien des logs apache / error_log et compagnie ?

    Idem pour le « restrict API » de Zend OP Cache, si tu as plus d’info ?

    Je serais curieux de rencontrer ta source semi-officielle en revanche… Ce qu’elle dit est bien loin de l’état d’esprit de l’équipe.

    Réponse
    • 21 avril 2016 à 16 h 40 min
      Permalink

      Wow, que d’infos et de nouvelles, grand merci à toi ! 🙂

      Est-il prévu que l’environnement passe en 64 bits du coup ou pas du tout ?
      Je vais creuser pour l’API alors 🙂

      J’avais fouiné un poil sur le .ovhconfig mais la doc « officielle » est pas super complète et je n’ai pas le réflexe forum. Je ne connaissais pas cette instruction, je vais essayer ça !

      Les logs Apache et tout, oui. Une fois sur deux, quand j’essaie d’y accéder, le site ne répond pas, que ce soit chez moi (Free), via 4G (Free aussi) ou au boulot (noeud RENATER). C’est juste ça 😉

      Je vais retrouver l’erreur exacte pour le Zend OP Cache, mais c’est parfois bloquant (genre Pydio 6 ne s’installait pas après le test qui renvoyait l’erreur, obligé de virer le test en question du code).

      Pour le reste, c’est pas une question d’équipe du tout, ou de bonne volonté, attention. Rassure toi !
      Tu as un mail chiffré ou truc du genre auquel je peux écrire sans que la planète lise ? 😀

      Réponse
  • 23 avril 2016 à 20 h 43 min
    Permalink

    J’attends avec impatience ce tutoriel mis-à-jour !

    Réponse
  • 24 avril 2016 à 6 h 40 min
    Permalink

    Bonjour Maxime,
    un petit HS: je lis que tu utilises Pydio sur une offre OVH mutualisée. j’ai une installation Pydio sur une offre perso. les temps de réponse sont très longs surtout pour les 1ères connexions, avec régulièrement un « MySQL server has gone away ». Ensuite, une fois entré dans le filesystem, la navigation est plus rapide.
    As tu les mêmes problèmes ? A ton avis est ce dû à la config ovh (offre perso) ou un paramétrage spécifique qui m’échappe ?
    A noter que la même install sur une offre 1ère prix 1And1 fonctionne correctement.
    Merci de ton retour

    Réponse
  • 24 avril 2016 à 20 h 12 min
    Permalink

    Bonjour,
    Exactement le même problème. Pas de mise à jour proposée par Owncloud!
    « Version: ownCloud 8.2.3 (stable)
    Updates will be available here within a few days after the announcement.
    Canal de mise à jour : Stable  »

    Repartir sur une installation complète me poserait beaucoup de soucis..
    Est-ce qu’un simple remplacement des anciens fichiers sur le serveur par les nouveaux version 9 (sauf « data et apps ») ferait l’affaire?

    Merci pour votre aide.

    Réponse
  • 26 avril 2016 à 21 h 20 min
    Permalink

    Bonjour petite question,
    après une installation propre comment puis-je récupérer mes comptes utilisateurs ? pour les données je copie le dossier data mais les comptes je ne sais pas.
    je suis sur une version 8.0.2 et je voudrait que le passage à la 9 soit transparent pour les amis à qui j’ai créé un compte de plus je ne me rappelle pas forcement de leur mot de passe pour recréer les compte un par un.
    merci d’avance

    Réponse
    • 27 avril 2016 à 12 h 55 min
      Permalink

      Bonjour,

      à moins de mettre à jour une instance existante, je ne sais pas si la migration de comptes est possible « simplement ».
      À voir, peut-être avec un import-export d’une partie de la base de données ?

      La documentation comprend une section sur la migration, mais « sans plus de détails » je ne me risquerais pas à importer une table issue de ownCloud 8.0 dans une instance en 9.0 (probablement pas mal de changements)…

      Réponse
      • 27 avril 2016 à 13 h 13 min
        Permalink

        Merci pour la réponse, je n’avais rien trouvé de clair effectivement dans la doc d’où ma question.
        je vais regarder du coté de la base de données sans conviction, la recopie de data je sais que ça fonctionne, mais après il faut recréer exactement tous les comptes à la main. c’est dommage. Mais la mise a jour me fait une page blanche a chaque fois donc pas possible.

        Réponse
        • 2 mai 2016 à 15 h 37 min
          Permalink

          Pour ma part, j’ai fait une sauvegarde de la base de données de OC 8.
          J’ai fait mon installation OC9 comme si c’était la première fois. puis déplacement des datas et réimportation de la base de données dans la nouvelle installation (faut bien penser à garder le même password d’une base à l’autre et faire un peu de ménage avant, comme supprimer les articles de la partie « news » ou autres trucs qui remplissent un peu la base…).

          il va falloir que je teste de mettre les datas dans une répertoire du serveur « à coté » d’OC pour gagner du temps la prochaine fois…

          Est-ce que je suis le seul à avoir des problèmes de cron avec OVH ? je le retrouve systématiquement suspendu…

          Réponse
  • 11 mai 2016 à 8 h 02 min
    Permalink

    J’ai testé l’installation de owncloud 9.0.1 et 9.0.2 chez OVH sur une offre Pro mutualisée.

    J’ai réussi à faire fonctionner la version 9.0.1 avec les manips décrites ci-dessus mais au bout d’un certain temps un bandeau « This operation is forbidden » est apparue en haut de la page d’accueil. Impossible d’accèder aux fichiers sur le cloud et ce quelque soit le compte utilisateur ou admin.

    J’ai tenté une installation frâiche et toute propre de la nouvelle version 9.0.2. Après avoir lancé l’installation je me connecte en tant qu’admin et je retrouve ce message « This operation is forbidden »…

    Rien de particulier dans la config. J’utilise le .ovhconfig pour pointer sur PHP 5.6. J’ai fait une installation de base avec SQLite pour tester avant migration totale vers MySQL.

    Une idée de ce qui pourrait poser problème ?

    Réponse
    • 11 mai 2016 à 8 h 14 min
      Permalink

      Il semblerait que cette erreur vienne du firewall… J’ai du ajouter cette ligne au .ovhconfig :

      http.firewall=none

      Pour que ça fonctionne….

      Réponse
      • 24 mai 2016 à 21 h 21 min
        Permalink

        J’ai le même souci sur la 9.0.2 mais la modif http.firewal=none dans le .ovhconfig ne règle pas le problème chez moi 🙁

        Réponse
        • 26 mai 2016 à 15 h 20 min
          Permalink

          Pour info, je n’ai pas le souci sur la 8.2.5

          Je vais attendre la 9.0.3 avant de tester à nouveau.

          Réponse
  • 20 mai 2016 à 11 h 00 min
    Permalink

    Merci pour le tuto…. mais ça plante toujours pour moi, sur un mutu pro.
    https://www.archipente.com/owncloud/
     » Mise à jour de l’application nécessaire
    Les applications suivantes seront mises à jour:
    WebDAV (dav) »
    avec un bouton mise à jour qui ne met rien à jour….

    C’est régulier les boutons qui sont inclicables chez moi, c’est normal?

    Merci d’avance!

    Réponse
    • 20 mai 2016 à 11 h 30 min
      Permalink

      Je me réponds: passer les file permissions en 777 résout mon pb…

      Réponse
  • 20 mai 2016 à 13 h 52 min
    Permalink

    Du coup, j’arrive à effectuer l’installation, mais impossible de me loguer: sur IE, je ne peux pas valider mon login, sur chrome, logué suite à l’installation, la page charge sans arrêt, impossible d’aller dans l’interface d’admin… des idées?

    Réponse
    • 24 mai 2016 à 22 h 40 min
      Permalink

      J’ai eu ce comportement quand je suis passé en PHP 7.0. Du coup, je suis revenu en 5.6

      Réponse
  • 24 mai 2016 à 21 h 36 min
    Permalink

    Bonjour Maxime,

    Pourrais-tu poster ton .htaccess ? j’ai un doute sur le mien

    Réponse
  • 30 mai 2016 à 12 h 40 min
    Permalink

    Bonjour,
    voulant mettre en place le HTTPS suivant les recommandations, j’ai suivi la manip (y compris la remarque de Olivier (Play With Free)) pour sur un hébergeur mutualisé (chez NUXIT) il m’est par la suite impossible d’accéder au service par le HTTPS.
    J’appuis la demande de GROM, est-il possible d’avoir le code du .htaccess ?
    Merci d’avance.

    Réponse
  • 10 juin 2016 à 15 h 07 min
    Permalink

    Bonjour à tous, 1 Question de newbie :
    Avec l’arrivée prochaine des certificats Let’ Encrypt chez OVH, sur un mutualisé Perso, ou conseillez-vous de mettre owncloud :
    – dans un sous domaine owncloud.domaine.fr
    – ou plutôt dans un « sous-dossier » domaine.fr/owncloud ?
    Chez moi (cluster13), toujours rien autour du HTTPS malgré les mails d’informations d’OVH (et donc, étant newbie), je suis également preneur d’un exemple de code .htaccess (celui à la racine de votre hébergement, comme celui dans le sous-dossier owncloud).

    Dernière question : ayant un site wordpress et ce futur owncloud sur mon serveur, un intérêt à passer sur une offre Pro plutôt que Perso ? (je ne vois que le fait de pouvoir avoir 2 bases MySQL, alors qu’en Perso, la MySQL est prise par WordPress et m’obligera à mettre owncloud sous SQLite).

    Merci d’avance pour votre aide.

    Réponse
      • 15 juin 2016 à 8 h 01 min
        Permalink

        Merci. Peu de différences avec le mien (par défaut), si ce n’est les « always » ajouté aux « Headers set ».
        A quoi sert cette ligne ajouté également aux Headers, que je n’ai pas à la base :
        « Header always set Strict-Transport-Security « max-age=15768000; includeSubDomains; preload »
        Merci d’avance.

        Réponse
        • 15 juin 2016 à 8 h 13 min
          Permalink

          C’est pour corriger une des erreurs (ownCloud attend que ce header soit défini) et surtout pour m’assurer que HSTS soit bien opérationnel. Je reconnais que je devrais également ajouter ça à ce blog, mais j’attends qu’OVH daigne déployer les certificats Let’s Encrypt à mon cluster 😀

          Réponse
  • 13 juin 2016 à 11 h 03 min
    Permalink

    Voici l’erreur dont on parle plus haut :

    {« reqId »: »j’ai masqué cette info », »remoteAddr »: »j’ai masqué cette info », »app »: »PHP », »message »: »Zend OPcache API is restricted by \ »restrict_api\ » configuration directive at \/home\/mon-id\/cloud\/lib\/private\/util.php#1365″, »level »:3, »time »: »2016-06-13T08:20:45+00:00″, »method »: »POST », »url »: »\/index.php », »user »: »–« }

    Réponse
  • 13 juin 2016 à 14 h 01 min
    Permalink

    Bonjour,

    Je suis un maxi newbie, à tel point que j’ai même du mal à comprendre le message de « newbie » de Pierre Martin…

    J’essaie d’installer owncloud sur mon hébergement OVH mutualisé. Pour info, j’ai déjà un site en wordpress installé.
    J’ai fait un premier d’essai d’installation d’owncloud dans un sous-domaine du type owncloud.monsite.fr, et cela fonctionne, si ce n’est les messages d’erreur (que je n’ai pas encore cherché à corriger) et l’avertissement lié à MySQL/SQLite.

    Dans le tuto, il est précisé : « Je vous conseille également d’utiliser MySQL et pas SQLite, si vous avez pas mal de fichiers et/ou de comptes, sinon, bonjour les dégâts et la base corrompue à mort (testé et désapprouvé). »
    Dans son dernier commentaire, Pierre Martin dit : « la MySQL est prise par WordPress et m’obligera à mettre owncloud sous SQLite ».

    N’y a t-il pas moyen que WordPress et owncloud partagent la même base de donnée ? C’est une question stupide, c’est ça ?

    Est-ce que si j’installe la version 8 d’owncloud j’aurai également cette contraite liée à SQLite ? J’ai pas l’impression que cela soit précisé dans les anciens tutos trouvés sur ce site.

    Ce que je souhaite, c’est tout simplement avoir mon propre cloud et m’affranchir de Dropbox et de Hubic pour synchroniser certains de mes fichiers de travail, peu importe la version.

    Merci de vos réponses !

    Réponse
    • 13 juin 2016 à 19 h 41 min
      Permalink

      Hello,

      il n’y a pas de question bête, si tu as une question c’est qu’il te faut une réponse 😉
      La base SQL proposée par OVH fait, de mémoire, 200Mo maximum. Le jour où mon WordPress (celui-là même sur lequel vous naviguez pour me lire) mangera les 200Mo, il virera sans hésiter.
      Si tu as déjà mis le nez dans la base de données, via PHPMyAdmin par exemple, tu as probablement remarqué que par défaut les tables de WordPress ont un nom commençant par « wp_ » : c’est ce qu’on appelle le préfixe, qui permet éventuellement de différencier les tables liées à WP de celles d’un autre outil, ici ownCloud. Dans mon cas donc, ils partagent tous deux (et même à plus de 2) une seule et même base de données, WordPress avec des tables commençant par « wp_ » et ownCloud par des tables commençant par « oc_ » .

      Effectivement je ne parle pas de ce souci dans les anciens tutoriels, tout simplement parce qu’à l’époque j’étais le seul à utiliser mon cloud, pour seulement quelques fichiers… J’ai été confronté à ce souci de manière un peu violente, et je donne ce conseil pour vous éviter la même crise de nerfs 😀

      Si tu as d’autres questions, je reste dispo 🙂

      Réponse
      • 14 juin 2016 à 14 h 19 min
        Permalink

        Bonjour,

        Merci pour la réponse, cela m’a permis de faire une installation propre sur la base de donnée et cela a bien marché. J’ai corrigé les erreurs comme indiqué dans le tuto, et il ne me reste que les erreurs liées à OVH.

        Je suis sous Mac OS X. J’ai installé le client owncloud et j’ai créé un fichier .profile sur la racine de mon dossier utilisateur (en tapant dans un terminal : echo ‘export OWNCLOUD_CHUNK_SIZE=1000000’ >> .profile ) puisque celui-ci n’existait visiblement pas, même en affichant les fichiers cachés.

        Malgré cela, lors de la synchronisation, j’ai plein d’erreurs du type :

        server replied: Internal Server Error (An exception occurred while executing ‘UPDATE `oc_file_locks` SET `lock` = -1, `ttl` = ? WHERE `key` = ? AND `lock` = 1’ with params [1465912776, « files\/bbd659faca2aa9a06f252f24add6deca »]:
        SQLSTATE[HY000]: General error: 2006 MySQL server has gone away)

        J’ai donc un doute sur le fait que mon .profile fonctionne, qu’il est bien placé, ou bien s’agit-il d’un autre problème ?

        Merci d’avance !

        Réponse
        • 15 juin 2016 à 8 h 29 min
          Permalink

          Bonjour,

          alors, une réponse en 2 temps 😉
          Mac OS est basé sur UNIX mais n’en a pas gardé toutes les spécificités. La façon de définir une variable d’environnement, entre autres, n’est pas exactement la même… tu peux a priori effacer le .profile que tu as créé, le système ne le prend pas en compte !

          Tu peux tester la prise en compte de la variable en suivant les instructions du github owncloud. Cette modification sera perdue au redémarrage, c’est juste pour voir si ça vire un peu tes erreurs.

          Pour la mise en place de cette variable, 2 options : la ligne de commande (je te renvoie vers ce topic qui explique tout, n’ayant pas de Mac je ne peux pas te dire si c’est clair), et les paramètres « classiques » de Mac OS. Dans ce second cas (et comme c’est plus simple ET que ça a été testé, je te conseille cette option), je te renvoie un peu plus haut vers le commentaire de @Zilkos qui détaille la procédure.

          J’espère que cela te débloquera !

          Réponse
    • 13 juin 2016 à 20 h 20 min
      Permalink

      Hello Cédric, je pense que nous en sommes à peu près au même point 😉
      J’ai moi aussi un mutu (perso) donc avec 1 seule base MySQL. J’ai déjà WordPress dessus, mais vu le retour, je vais voir pour y mettre aussi les tables oc…
      En tout cas mon but est le même que le tien : me passer de dropbox pour héberger mes fichiers et ce de mes proches (10 personnes max).

      Questions pour les connaisseurs :
      – comment faire pour mettre les tables owncloud dans la même base (j’imagine qu’il faut renseigner les infos de la base MySQL existante dans le fichier de config de owncloud, mais comment lui dire de créer des tables « oc… », le fait-il tout seul ?
      – owncloud stocke quoi dans la base, pas les fichiers j’imagine ? (sinon les 200Mo seront vite rempli) ; donc vous conseillez de rester sur un Mutu Perso (avec wordpress et owncloud dans une même base MySQL), ou de passer plutôt sur un Mutu Pro (avec 2 bases) ?

      Merci d’avance.

      Réponse
      • 14 juin 2016 à 8 h 50 min
        Permalink

        Hello,

        ownCloud installe les tables SQL avec son propre préfixe, tout comme WordPress le fait avec les siennes. On peut parfois le modifier au moment de l’installation (comme avec WP) mais pour ownCloud je ne crois pas, mais bon, tu ne veux qu’une seule instance je suppose 😉 ).
        Dans la base il stocke l’index des fichiers et les infos associées, les comptes utilisateurs, les réglages, les quotas, les propriétaires des fichiers, les partages, l’activité, les données des applications que tu peux installer/activer… Tout plein de choses, finalement 😉
        Dans mon cas tout ça ne prend que quelques Mo ! Pas de panique, je ne suis jamais arrivé à 50Mo avec tout ce que j’ai sur le mutualisé, alors 200… :mrgreen:

        Pour ton utilisation perso, je te conseille de rester sur une offre perso, après il sera toujours temps de changer si tu te sens à l’étroit ou limité… 😉

        Réponse
        • 14 juin 2016 à 10 h 52 min
          Permalink

          Merci beaucoup Maxime pour ces retours chiffrés, cela m’aide en effet à prendre la bonne décision. Il ne me reste plus qu’à essayer de résoudre les problèmes de php-fpm et autres. Si tu as des idées, je suis preneur évidement 😉

          Réponse
  • 13 juin 2016 à 21 h 09 min
    Permalink

    Le premier message d’erreur après une installation 9.0.2 (stable) et SQLite :
    « php does not seem to be setup properly to query system environment variables. The test with getenv(« PATH ») only returns an empty response.
    Please check the installation documentation ↗ for php configuration notes and the php configuration of your server, especially when using php-fpm. »
    Or la doc semble indiquer qu’il faut changer des valeurs dans un fichier de config de php-fhm, lequel est (si je comprends bien) inaccessible sur un mutualisé, exact ?

    Une idée Maxime Auvy (et encore une fois merci pour ces tutos et l’aide apportée).

    Réponse
    • 15 juin 2016 à 8 h 15 min
      Permalink

      C’est ça, c’est a priori la seule erreur pour laquelle on ne peut pas faire grand chose. Il s’agit d’une erreur / restriction des stacks web mutualisés chez OVH.
      Ça ne semble pas me poser de soucis au quotidien, pour autant…

      Réponse
  • 14 juin 2016 à 22 h 30 min
    Permalink

    bonsoir

    je sollicite votre aide .. j’avais réussi à installer OC version 8 grâce à votre tuto (merci ;); suite à un crach de ma base de données , je n’ai pas plus me connecter. du coup , j’essaye d’installer OC version 9 mais je cale … dès la page d’installation !
    Nom d’utilisateur = pas problème
    Mot de passe = pas de problème
    Répertoire de données = Aie ! que dois-je mettre ? ; laisser l’adresse par défaut ? c-a-d
    /home/nom_du_compte/cloud/data ( j’ai laissé par défaut)
    je decide l’installer MySQL ( j’ai installé la BDD sur OVH)
    Nom de la base = pas de problème
    Mot de passe = pas de problème
    Nom de la base de données = A priori le même nom que celui de la base …
    localhost = ?… je ne sais pas si je dois laisser ce paramètre ou non ?, (j’ai laissé par défaut)

    Resultat :
    « Error while trying to create admin user: Failed to connect to the database : An exception occured in driver : SQLSTATE »HYP000″ »2002″Can’t connect to local MySQL server through socket ‘var/run/mysqld/mysqld.sock'(2)

    j’en suis là…

    je vous remercie pour votre aide

    Réponse
    • 15 juin 2016 à 8 h 20 min
      Permalink

      Bonjour,

      alors, nom d’utilisateur et mot de passe, c’est à toi de choisir 😉
      Le répertoire des données, tu peux laisser par défaut. C’est simplement que dans certains cas particuliers, les administrateurs souhaitent que les fichiers des utilisateurs soient à l’extérieur du répertoire owncloud, pour tout un tas de raisons propres à chaque cas.

      Pour la base de données : utilisateur et mot de passe sont ceux utilisés par PHPMyAdmin et autres, et le nom de la base est a priori identique au nom d’utilisateur (bon ok c’est l’inverse, mais au final c’est le même nom 😛 ).
      Pour l’emplacement, l’hôte ou je ne sais plus comment ils appellent ça : ce n’est pas localhost qu’il faut entrer (d’où ton erreur) mais le nom du serveur hébergeant ta base, de la forme mysqlx-x.perso probablement. Il est accessible dans ton Manager OVH, dans la partie qui traite de la base de données.

      J’espère que tu pourras ainsi passer l’étape de l’installation 🙂

      Réponse
  • 17 juin 2016 à 17 h 49 min
    Permalink

    Bonjour Maxime,
    je te remercie pour ton aide. j’ai suivi « texto » ton explication , et ça marche !
    merci à toi ,
    ( pour info, ca n’a pas fonctionné du 1 er coup, j’ai eu un problème sur ma BDD MySQL .. ( encore ?) )
    je ne sais pas pourquoi à l’installation, les tables OC ne se sont pas mises dans mySQL,
    du coup, j’ai tout repris à zero, installation de la base de données My SQL sur OVH puis rapatriement d’OC avec le FTP et là, c’est bon ..
    je me suis certainement craqué à un moment donné …
    Bon Week-end

    Réponse
  • 21 juin 2016 à 14 h 46 min
    Permalink

    Salut,
    Concernant OWNCLOUD_CHUNK_SIZE, plus besoin de créer de variable d’environement avec les dernières version du clients : il suffit d’ajouter la ligne
    chunkSize=1000000
    sous la section [General] du fichier de configuration ($HOME/.local/share/data/ownCloud/owncloud.cfg sous linux).

    Réponse
    • 21 juin 2016 à 18 h 03 min
      Permalink

      Salut,

      Merci du tuyau. Sous Mac, j’essaie désespérément de changer la variable mais cela ne marche jamais.
      Et pareil, quand j’essaie de modifier le fichier de configuration, je ne le trouve pas… La documentation owncloud indique qu’il est censé être là : $HOME/Library/Application Support/ownCloud
      Mais rien à faire… Impossible de changer ce paramètre, je reste bloqué…

      Réponse
      • 23 juin 2016 à 11 h 42 min
        Permalink

        Tu peux toujours spécifier le chemin du fichier de configuration avec l’option –confdir.

        Réponse
        • 23 juin 2016 à 16 h 43 min
          Permalink

          Alors je viens de tenter de créer un répertoire ownCloud à l’endroit où il devrait être (sudo mkdir /Library/Application\ Support/ownCloud/) puis je tape la ligne de commande suivante :

          /Applications/owncloud.app/Contents/MacOS/owncloud –confdir /Library/Application\ Support/ownCloud/

          Et là, j’ai une fenêtre graphique de configuration du serveur que je remplis, il se connecte avec succès.

          Puis quand j’essaie d’aller récupérer mon dossier config, je me rends compte que /Library/Application\ Support/ownCloud/ est complètement vide. Même en faisant un ‘ls -a’ je n’ai rien du tout…

          Je n’y comprends plus rien…

          Réponse
    • 4 juillet 2016 à 13 h 27 min
      Permalink

      Hello,

      j’utilise NextCloud depuis sa sortie, via l’interface Web c’est très bien, mais via le client ownCloud sous Mint j’ai pas mal d’erreurs, sans raison. Le client NextCloud Android (installé depuis F-Droid » refuse de s’initialiser, pour cause d’ « Erreur inconnue » . Pour le reste, je n’ai pas encore testé… J’espère que ce souci sera corrigé rapidement 😕

      Réponse
  • 19 juillet 2016 à 12 h 20 min
    Permalink

    Bonjour,

    Je continue à galérer avec la configuration du client pour régler le paramètre chunksize. Après avoir été incapable de trouver comment faire pour régler les variables d’environnement de façon efficace sous Mac OS X, j’ai réussi à trouver le fichier de configuration de owncloud (il était bien caché, il est invisible en ligne de commande…).

    La documentation précise de mettre le paramètre de chunksize dans la section [ownCloud] du fichier, laquelle n’existe pas.
    J’ai donc tenté de mettre le paramètre dans la section [General]. Et quand je lance la synchronisation, j’ai ce type d’erreur : Error downloading https://xxx/xxx.jpg-chunking-3779268617-4-2 – server replied: Locked

    J’ai même tenté de créer une section [ownCloud], mais j’ai de nouveau les Timeout du serveur SQL.

    Une idée pour résoudre ce problème ?

    Merci et bonne journée !

    Réponse
    • 2 août 2016 à 5 h 47 min
      Permalink

      Hello,

      Je me réponds, au cas où certaines personnes cherchent la solution aux problèmes que je citais.

      1) Je n’ai plus de problème avec les variables ou le fichier de configuration : mettre le paramètre dans la section [General] marche très bien.
      2) les erreurs de locked files que j’avais n’avaient rien à voir directement avec le paramètre de Chunksize. D’après mes longues recherches, il semblerait que les premiers essais infructueux de transfert de fichiers (avant de régler le chunksize) auraient mis les fichiers dans une liste bloquée. Je me suis donc connecté à PHPMyAdmin et j’ai supprimé tous les éléments présents dans la colonne oc_file_locks (en faisant bien attention à ce que je faisais…).
      3) J’avais également des erreurs de fichiers ignorés. J’ai ainsi réalisé que j’avais quelques fichiers temporaires (surtout des fichiers Word) que j’ai supprimés.
      4) J’avais un dossier qui faisait plus de 500 Mo. Le client m’alertait en permanence en me disant qu’il avait désactivé la synchronisation. Il s’avère qu’il y a une option, dans le client, qui permet de demander confirmation quand un dossier dépasse une certaine taille. On peut désactiver l’option ou augmenter la taille limité.

      Je me retrouve donc maintenant avec tous mes fichiers correctement synchronisés et sans erreur supplémentaire !
      Par contre, j’ai un peu peur de faire la mise à jour vers la version 9.1 et au-delà sans que cela casse tous les réglages !!

      Réponse
    • 5 août 2016 à 21 h 14 min
      Permalink

      Bonjour Cédric et Maxime.
      Merci Maxime pour ce tuto de dingue.
      Cédric, je suis aussi à la recherche de owncloud.cfg sous Mac OS X. Peux-tu me dire où il est situé ? Et les changements que tu as effectués, s’il te plait ?
      Au passage, je n’ai pas le dossier « owncloud » dans /HOME/Library/Application Support/ comme j’ai pu trouver sur le net…
      Merci d’avance,
      Nicolas.

      Réponse
      • 8 août 2016 à 8 h 20 min
        Permalink

        Bonjour Nicolas,

        Le fichier est bien situé dans /home/Library/Application Support, mais il est invisible en ligne de commande, pour une raison que j’ignore… Je l’ai cherché pendant des jours, écumé tous les forums, posté des messages dans le forum officiel d’owncloud, rien à y faire.
        Et puis finalement, j’ai trouvé quelqu’un qui disait comment y accéder avec Finder. Il suffit d’aller dans le menu « Aller » et d’appuyer sur la touche ‘alt’, et le dossier ‘Bibliothèque’ (en français puisque mon Mac est est français) est visible, avec tous les fichiers dont le dossier owncloud…

        Dans le fichier, sous la section [General], il suffit de rajouter :
        chunkSize=1000000
        puis de redémarrer le client et le tour est joué.

        Réponse
        • 8 août 2016 à 11 h 06 min
          Permalink

          Merci, merci, merci ! J’ai enfin pu uploader un fichier de taille supérieure à 1 Mo !
          C’est tout bête en fait, encore faut-il le savoir !
          Je vais précieusement garder toutes ces instructions pour la suite.
          🙂

          Réponse
  • 23 juillet 2016 à 22 h 46 min
    Permalink

    Bonjour,

    J’ai suivi la procédure d’installation…nickel, du moins à peu près car en cours d’install un page d’erreur apparait…mais en actualisant…ça repart.

    Maintenant j’ai une proposition de mise à jour vers la 9.0.4, je clique sur le bouton…et il ne se passe rien !
    J’actualise la page pour voir les logs d’erreur : à chaque clic sur le bouton « ouvrir le système de mise à jour », 2 nouvelle lignes apparaissent en log :
    Error PHP Undefined index: REQUEST_URI at /home/antipodebq/www/owncloud/lib/base.php#179
    et
    Error PHP Zend OPcache API is restricted by « restrict_api » configuration directive at /home/antipodebq/www/owncloud/lib/private/util.php#1365

    Une idée là-dessus…?
    D’avance merci…

    Réponse
    • 24 juillet 2016 à 10 h 17 min
      Permalink

      Je me réponds…
      J’ai préféré faire une mise à jour « manuelle » vers 9.1… problème réglé.
      Si vous faites de même pensez bien à changer les droits d’accès aux fichiers.

      Réponse
      • 30 juillet 2016 à 0 h 06 min
        Permalink

        Bonjour,

        Comment as-tu procédé ? Tu as juste extrait les fichiers de la 9.1 à la place de l’installation existante ? Est-ce que cela a écrasé les fichiers modifiés dans ce tuto (sous-entendu : est-ce que l’on doit suivre de nouveau les étapes du tuto pour corriger les erreurs ?)
        Que veux-tu dire par « pensez bien à changer les droits d’accès aux fichiers » ? Comment faire ?

        Merci pour ces réponses !!

        Réponse
        • 22 août 2016 à 8 h 46 min
          Permalink

          Bonjour,
          Désolé pour la réponse tardive…
          Pour la mise à jour manuelle, en résumé :
          Renommer avec un client ftp le dossier owncloud en owcloudbak;
          Déposer les fichiers décompressés sur le serveur;
          Déplacer (ou copier) les dossiers config et data de owcloudbak vers owncloud et le fichier .htaccess (du coup pas besoin de refaire la config ni les modifs du tuto).

          Pour changer les droits, n’arrivant pas à faire fonctionner une console ssh j’utilise filezilla : clic droit sur owncloud et modification des droits d’accès aux fichiers.

          Réponse
          • 23 août 2016 à 7 h 54 min
            Permalink

            Merci pour cette réponse, cela semble fonctionner. Quels droits as-tu affecté ?

          • 23 août 2016 à 8 h 17 min
            Permalink

            Je l’ai joué un peu imprudent en donnant 777… mais cela fonctionne.
            A l’occasion, je ferai des tests en limitant les permissions publiques (775, 774 voire 770 comme souvent recommandé).

    • 26 juillet 2016 à 9 h 58 min
      Permalink

      Bonjour,

      Même problème chez moi. Tu utilise quelle version de php ? Chez moi c’est php 7.

      Réponse
      • 26 juillet 2016 à 12 h 33 min
        Permalink

        J’utilise php5.6… Ne trouvant pas de solution, j’ai préféré la mise à jour manuelle… pas si compliquée que ça à faire… D’autant que la MAJ automatique ne me proposait pas la 9.1

        Réponse
        • 26 juillet 2016 à 17 h 04 min
          Permalink

          Mise à jour manuelle faite. J’ai un problème avec owncloud news qui réclame un système 64 bits…

          Réponse
  • 4 août 2016 à 8 h 55 min
    Permalink

    Bonjour,

    Merci pour ce super tuto et également les supers commentaires qui se trouvent après qui aident bien aussi.

    Alors chez moi (OVH perso mutu / PHP 5.6 / OC 9.1 et WP à la base du mutu).

    Tout fonctionne impec! Sauf (oui y’en a un) quand j’essaie d’accéder à OC depuis mon client (ubuntu) :
    1 – (c’est peut être rien mais) Seul le format https://www.domaine.fr/oc donne accès à l’étape d’après (login et mdp).
    Si je change le https -> en http ou si j’enlève le www il n’arrive pas à aller plus loin, soit il tourne dans le vide (et redémarre le client) soit il m’affiche « erreur de la connexion à oc pour https://domaine…/statuts.php error downloading https://domaine…/statuts.php – server replied bad request »

    2 – Dans le cas où j’accède au login et mdp (et j’ai essayé de modifier les logins et mdp) il m’indique systématiquement « erreur : paramètres de connexion invalides. »

    Pour info depuis la tablette j’accède parfaitement au serveur sans soucis (j’ai pas encore essayé depuis un autre ordi j’en ai pas sous la main de suite).

    Une idée?… Car un OC sans synchronisation sur ordi c’est mignon mais c’est un tout petit …

    Merci d’avance et merci encore!

    Réponse
    • 5 août 2016 à 17 h 34 min
      Permalink

      Réponse à moi même 😉

      Concernant le problème n°2 j’ai trouvé la solution! en espérant que ça en aide d’autres:
      – Le problème venais de la version de mon client : Version trop ancienne.
      – J’ai donc supprimé le client !mais aussi! les fichiers tmp liés (/tmp/sni-qt_owncloud_…) et dans dossier personnel/.local/share/date/owncloud puis fait une mise à jour du dépot owncloud et réinstaller le tout. Ça fonctionne!

      Pour le problème n°1 j’ai une idée mais avant de faire n’importe quoi je vous demande une confirmation :
      – Dans OC/config/config.php une ligne ‘overwrite.cli.url’ => ‘https://www.mondomaine.fr/owncloud’, apparaît. Cela changerait-il quelque chose de rajouter d’autres lignes de forme : ‘overwrite.cli.url’ => ‘https://mondomaine.fr/owncloud’, etc. ?

      Nouveau problème :
      – Impossible d’uploader des fichiers volumineux malgré avoir ajouter chunksize. Avant de m’alarmer de vais regarder la discussion au dessus car certains messages en parlent.

      Réponse
  • 25 août 2016 à 22 h 38 min
    Permalink

    Bonjour,

    Ce tuto très utile m’a permis de régler bon nombre de problèmes. Pourtant il y en a 1 qui persiste et devant lequel je suis dubitatif :
    Depuis une installation toute fraiche, le menu « Fichiers » de owncloud n’affiche aucun dossier et une erreur : « Cette opération est interdite ».
    Par contre pas de soucis pour accéder à la « Gallerie » ou aux « Activités »…
    J’ai ré-installé pour voir. Même punition.
    Je suis sur un mutualisé Perso 2010 d’OVH.

    Bien à vous

    Réponse
    • 19 novembre 2016 à 13 h 42 min
      Permalink

      J’ai trouvé la réponse, alors je vous en fait part :
      Pour que OwnCloud fonctionne normalement, j’ai dû désactiver :
      1/ Le FireWall du nom de domaine
      2/ Le Pare-feu applicatif de la configuration global de php

      Depuis, tout va bien

      Cordialement

      Réponse
  • 29 août 2016 à 16 h 34 min
    Permalink

    Salut et un grand merci pour ce très bon tutoriel !

    J’ai suivi chaque étape méticuleusement — la seule qui me laisse perplexe est la 2a : il n’y a en effet aucun « pavé qui cause les headers » dans mon .htaccess — et OwnCloud semble désormais convenablement installé dans un sous-domaine de mon espace mutualisé OVH. J’ai créé un compte utilisateur, voire deux, et je parviens à me connecter sans souci via mon browser.
    En revanche… impossible de me connecter en webDAV, ni via Os X ni via Ubuntu (dernières versions du client installées). Le Connection Wizard me répond systématiquement « Access forbidden by server », et me donne le lien vers le browser login.
    J’ai vu ailleurs que ce problème était souvent lié à des mots de passe contenant des caractères spéciaux, mais ce n’est pas le cas des miens.

    Je m’efforce de débroussailler le contenu de dizaines de différents forums depuis un bon moment maintenant, sans succès… Quelqu’un aurait-il une idée ?

    Au cas où, voici le log OwnCloud :
    Exception: {« Message »: »HTTP\/1.1 401 No ‘Authorization: Basic’ header found. Either the client didn’t send one, or the server is mis-configured », »Exception »: »Sabre\\DAV\\Exception\\NotAuthenticated », »Code »:0, »Trace »: »#0 [internal function]: Sabre\\DAV\\Auth\\Plugin->beforeMethod(Object(Sabre\\HTTP\\Request), Object(Sabre\\HTTP\\Response))\n#1 \/home\/ ### \/3rdparty\/sabre\/event\/lib\/EventEmitterTrait.php(105): call_user_func_array(Array, Array)\n#2 \/home\/ ### \/3rdparty\/sabre\/dav\/lib\/DAV\/Server.php(446): Sabre\\Event\\EventEmitter->emit(‘beforeMethod’, Array)\n#3 \/home\/ ### \/3rdparty\/sabre\/dav\/lib\/DAV\/Server.php(248): Sabre\\DAV\\Server->invokeMethod(Object(Sabre\\HTTP\\Request), Object(Sabre\\HTTP\\Response))\n#4 \/home\/ ### \/apps\/dav\/appinfo\/v1\/webdav.php(56): Sabre\\DAV\\Server->exec()\n#5 \/home\/ ### \/remote.php(164): require_once(‘\/home\/###\/…’)\n#6 {main} », »File »: »\/home\/ ### \/3rdparty\/sabre\/dav\/lib\/DAV\/Auth\/Plugin.php », »Line »:188, »User »:false}

    et le log OVH :
    [Mon Aug 29 16:55:42 2016] [error] [client 45.56.159.37] [host +++.fr] (32)Broken pipe: Error writing request body to script /homez.152/###/remote.php
    [Mon Aug 29 17:03:05 2016] [error] [client 45.56.159.37] [host +++.fr] (104)Connection reset by peer: ap_content_length_filter: apr_bucket_read() failed
    [Mon Aug 29 17:03:05 2016] [error] [client 45.56.159.37] [host +++.fr] (104)Connection reset by peer: Failed to flush CGI output to client
    [Mon Aug 29 17:03:50 2016] [crit] [client 45.56.159.37] [host +++.fr] (13)Permission denied: /homez.152/###/data/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable

    (une erreur de permissions du .htaccess ?)

    et pour finir, le contenu du .htaccess à la racine de mon dossier OwnCloud :
    RewriteEngine on
    SetEnv PHP_VER 5_6
    ErrorDocument 403 /owncloud/core/templates/403.php
    ErrorDocument 404 /owncloud/core/templates/404.php
    RewriteBase /owncloud
    RewriteCond %{HTTPS} off
    RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

    Réponse
    • 6 mars 2017 à 17 h 37 min
      Permalink

      Salut à tous,
      Je re-tente le coup, juste au cas où…

      Suis-je seul à ne pouvoir jamais me connecter par WebDAV ? (cf. mon précédent message)
      Je fouille et refouille le web, mais les seules solutions que je trouve au fameux problème « No basic authentication headers were found » demandent de modifier l’environnement Apache (vhost, etc.), ce qui est impossible sur un mutualisé si je comprends bien.
      Ex : https://www.christianroessler.net/tech/2015/owncloud-on-debian-jessie-with-apache-2.4-and-php-fpm.html
      https://central.owncloud.org/t/no-basic-authentication-headers-were-found-message/819
      etc<

      J'ai bien suivi les instructions du tuto, vérifiées puis retentées plusieurs fois…
      Mon fichier .htaccess est comme indiqué ci-dessus (avec une ligne en plus :
      Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains; preload")

      Tout conseil serait le bienvenu !
      Merci d'avance

      Réponse
      • 6 mars 2017 à 17 h 42 min
        Permalink

        Addendum : Une nouvelle erreur semble désormais apparaître dans mon log OwnCloud (elle n’y était pas en août dernier)…

        Cannot modify header information – headers already sent by (output started at /home/owncloud/3rdparty/sabre/http/lib/Sapi.php:83) at /home/owncloud/3rdparty/sabre/http/lib/Sapi.php#63

        La clé du mystère ?!

        Réponse
          • 7 mars 2017 à 13 h 00 min
            Permalink

            Quel est ton niveau de php ? (dans .ovhconfig )
            Je pense que la ligne SetEnv PHP_VER 5_6 dans ton .htaccess ne sert à rien.
            Pour ma part, j’ai choisi php 7.0 et tous mes sites fonctionnent (Joomla, webtrees, nextcloud, Piwigo …)
            À ta place, je recommencerai une installation complète à partir de NC 11.02

          • 14 mars 2017 à 17 h 49 min
            Permalink

            Merci merci merci ! Il y avait effectivement un problème de .htaccess, à présent corrigé — et ça marche !
            (quelques bugs à corriger encore, mais bon)
            Longue vie à toi.

  • 12 septembre 2016 à 16 h 33 min
    Permalink

    Bonjour,

    J’ai effectué la mise à jour de la version 8 à la version 9.
    Comme apparemment de nombreuses personnes d’après les forums, j’ai été surpris de ne pas voir CalDav.
    Je l’ai donc réinstallé.
    Néanmoins, le calendrier est vide, j’ai perdu toutes mes données précédentes !
    (et je n’avais « bien entendu » pas fait de sauvegarde…)

    Est-ce que vous connaissez un moyen de récupérer ces données ?

    J’espère être suffisamment précis, étant un newbie de toutes ces choses-là…

    Merci d’avance et bravo pour les tutos successifs, jusqu’ici je n’avais eu aucun soucis à « corriger » les défauts de l’hébergement OVH grâce à vous !

    Réponse
    • 18 décembre 2016 à 15 h 32 min
      Permalink

      Bonjour,
      J’ai eu exactement le même problème 😐
      Je n’ai pas trouvé la solution mais je fais maintenant un export de mes contacts et de mon calendrier avant de mettre à jour…

      Pour information j’ai réussi à faire fonctionner les maj automatiques sur Nextcloud / OVH en passant le PHP en version « stable ».

      Réponse
  • 1 octobre 2016 à 20 h 18 min
    Permalink

    Bonsoir
    et merci bcp bcp pour tes tutos
    catégorie newbie, OVH, Pro2014, j’ai upgradé oC de 7 à 9
    mais la MAJ ne se fait pas : « Exception: Updates between multiple major versions and downgrades are unsupported. »
    dans la page conseillée https://forum.owncloud.org/viewtopic.php?f=17&t=32087
    je ne sais pas faire : »Run the update via the webgui or the occ command line tool »
    dois-je tout ré-installer à neuf ou y-aurait-il un moyen d’executer l’update ?
    sinon comment récupérer tout le webcal ?

    merci bcp

    Réponse
    • 27 octobre 2016 à 11 h 07 min
      Permalink

      Hello (et désolé du délai de réponse 😕 ),

      le souci est « simplement » que la mise-à-jour automatisée ne supporte pas les sauts de versions majeures. Pour passer de oC 7 à 9, il faudrait soit faire 7 > 8 > 9 (en prenant en compte les autres versions intermédiaires, de mémoire passer de 8 à 8.2 oblige à faire manuellement la mise à jour 8 > 8.1 par exemple), soit faire une installation propre et y remettre tes fichiers et autres.

      Je te conseille sincèrement cette 2e option, tu repartiras sur une base saine.
      Tu peux également choisir de remplacer ownCloud par NextCloud. Ce n’est ni un conseil ni une obligation, je le mentionne seulement. A toi de voir 😉

      Pour les fichiers, je suppose que tu les as déjà en local, sinon un coup de FTP pour les rapatrier et c’est réglé.
      Pour les contacts et agendas, il te suffit de les exporter depuis leurs applications respectives. Tu devras exporter les calendriers un par un si tu en as plusieurs (je parle bien de calendriers, genre « Personal », pas des événements qu’ils contiennent), et même chose pour les carnets d’adresse dans Contacts.

      J’espère t’avoir été utile 🙂

      Réponse
      • 12 novembre 2016 à 21 h 59 min
        Permalink

        Merci beaucoup pour ce tuto.
        J’ai installé owncloud 9.1.2 sur un hébergement OVH perso mutualisé.
        Après avoir passé toutes les étapes restent:
        « 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.
        Veuillez consulter la documentation d’installation ↗ pour savoir comment configurer php sur votre serveur, en particulier en cas d’utilisation de php-fpm.  »
        Le souci semble venir d’OVH, vont-ils faire quelque chose ?

        Et Aussi: « Zend OPcache API is restricted by « restrict_api ». OVH encore…

        En tout cas merci pour ce tuto 🙂

        Réponse
  • 14 octobre 2016 à 9 h 26 min
    Permalink

    Bonjour,

    Merci pour ce tuto, j’ai finalisé l’installation d’une version 9.1.0.15 sur un mutualisé OVH en sous-domaine.

    Concernant les documents, j’aimerai qu’OC prenne en charge MS Word. Il est indiqué :

     » openOffice/LibreOffice est installé sur ce serveur. Le chemin vers le binaire est fourni via preview_libreoffice_path dans config.php  »

    Est-il possible d’installer OO/LO sur un mutualisé ? Comment ? Je n’ai rien trouvé…

    D’avance merci
    Badidon

    Réponse
  • 9 janvier 2017 à 19 h 30 min
    Permalink

    Merci, Maxime, pour ce tuto.
    J’ai passé directement ma version OC 9.xx en NextCloud 11.0.0.10 : tout s’est super bien passé. J’avais un peu peur que la base de données ne soit plus compatible, mais il n’y a pas eu de pb. Comme d’hab. (cf un vieux post), je n’ai pas eu besoin d’ajouter les lignes https dans mon .htaccess et je ne sais toujours pas pourquoi ça fonctionne comme ça chez moi avec les infos dans le config.php ( ‘trusted_domains’ =>
    array (
    0 => ‘sousdomaine.domaine.fr’,
    ),
    ‘overwrite.cli.url’ => ‘https://sousdomaine.domaine.fr’, )
    Vola, merci encore.

    Réponse
  • 29 janvier 2017 à 13 h 55 min
    Permalink

    Bonjour,

    J’essaie d’installer Owncloud 9.1.3 sur un OVH mutualisé mais j’obtiens toujours un avertissement relatif au .htaccess dès la première page d’installation :

    « Votre répertoire de données est certainement accessible depuis l’internet car le fichier .htaccess ne fonctionne pas. »

    Si j’ignore ce message et que je poursuis l’installation j’obtiens une erreur => fin du match.

    Pourriez-vous m’aider svp ?

    Réponse
    • 29 janvier 2017 à 14 h 06 min
      Permalink

      Bonjour. Je n’ai jamais eu cette erreur.
      Tu as bien le répertoire en droit d’accès 705 et le fichier .htaccess en 604 (lire et écrire pour le propriétaire, lire pour les autres ?)
      To .ovhconfig est bien configuré ? Moi, j’ai mis :
      app.engine=php
      app.engine.version=7.0
      http.firewall=none
      environment=production

      Mais j’ai laissé tomber Owncloud en faveur de NextCloud(ce qui ne doit rien changer pour ton pb.)

      Réponse
      • 29 janvier 2017 à 14 h 17 min
        Permalink

        Merci pour ta réponse.

        J’ai même tout passé en 755 pour voir. => même résultat.
        J’ai mis php version 5.6, 7.0 ou 7.1 avec le même résultat.

        Tous les dossiers et fichiers d’archive sont directement à la racine. Le problème peut-il venir de là ?

        Réponse
  • 29 janvier 2017 à 14 h 29 min
    Permalink

    Mon domaine principal étant dolman, mon installation de OC a été faite sous le répertoire /home/dolman/wwwO (plus souvent appelé /home/dolman/owncloud dans les exemples)
    C’est à dire, pour être certain que tu sois au bon endroit, tu dois avoir un répertoire cgi-bin, un répertoire requetes , un fichier Lisezmoi, tes répertoires de sites web et en particulier ton répertoire OwnCloud, et tous les fichiers owncloud sous ce répertoire OwnCloud (ou un autre nom, peu importe)
    Après, il faut, bien entendu que dans ton manager OVH tu fasses pointer ton nom de sous domaine vers ce répertoire.
    Difficile à expliquer sas savoir quel est ton degré de connaissance là dessus, mais j’essaie d’être au plus bas niveau.

    Réponse
  • 29 janvier 2017 à 14 h 42 min
    Permalink

    J’ai bidouillé des forums phpBB il y a quelques années mais ça me semblait plus simple à l’époque 🙂

    Pour reprendre sur de bonnes bases j’ai retiré les dossiers owncloud et je viens de télecharger nextcloud 11 qui me semble pas mal.

    Actuellement sur FileZilla j’ai ceci :

    /
    __home
    ____e
    ______b
    ____ebird
    ______www
    ______.ovhconfig

    .ovhconfig est le seul fichier.
    ebird.fr est mon nom de domaine.
    Je ne sais pas d’où sortent les dossier « e » et « b », qui sont vides.
    Je n’ai pas de dossier cgi-bin.

    Qu’en penses-tu ? 😀

    Réponse
  • 29 janvier 2017 à 15 h 04 min
    Permalink

    C’est normal; je crois que le dossiers e et b sont des liens symboliques vers ebird ou le contraire. Mais normalement, OVH livre avec des fichiers et répertoires qu’ils recommandent de ne pas effacer (cgi-bin, requetes, Lisezmoi, .bash-history …) mais je doute qu’ils soient vraiment utiles.
    Je suppose que tu dé-compresse l’archive en local sous un répertoire et que tu transferts le contenu de ce répertoire avec Filezilla vers ton répertoire www.
    J’ai déjà eu des pépins à ce niveau là car Filezilla avait (oublié ou tronqué) un fichier; donc il faut vérifier (cntrl-o avec FileZilla) que le contenu de ton répertoire www soit bien strictement identique au contenu de ton répertoire local (c’est très long si on veut tout vérifier) . Après, il faut vérifier que dans ton config.php il n’y ait pas le « installed->’true’ puis, avant de commencer,; que ta base de données existe (je crois me souvenir qu’elle n’est pas créé par OC qui ne crée que les tables dans une base existante)

    Réponse
  • 1 février 2017 à 17 h 14 min
    Permalink

    Pour répondre à Olivier (un peu tardivement), je crois être aussi affecté par ce bogue (https://github.com/nextcloud/server/issues/223)
    Je suis sous NextCloud 11.0.1.2 ; le client nextcloud fonctionne sur mon ordi en local et sur mon tél. Andoïd
    Le calendrier fonctionne et se synchronise sur Thunderbird en local mais : impossible d’utiliser DavDroid : quoi que je mette pour mon calendrier ou mes contacts, il me répond qu’il n’a pas trouvé de service CalDav ou CarDav. J’ai essayé de modifier le fichier base.php comme expliqué sur github, (ajout de ‘/^DAVdroid/’ ) mais ça n’a rien changé.
    Quelqu’un aurait-il une solution ? Il semble que ce problème soit lié à OVH.

    Réponse
  • 1 février 2017 à 21 h 09 min
    Permalink

    Bon, toujours pareil : couldn’t find CalDav or CarDav services.
    D’où sort ce « pricipale » ? Quelque chose a du m’échapper dans la doc.
    Par ailleurs (ça n’a rien à voir) je trouve que mon adresse https://testb.dolman.fr/ est extrêmement longue à charger (je suis sous OVH pro2014)
    PS. sur la page NextCloud Agenda, paramètres, l’adresse indiquée est bien : https://testb.dolman.fr/remote.php/dav/

    Réponse
  • 1 février 2017 à 21 h 13 min
    Permalink

    Normalement, je devrais recevoir un nouveau téléphone demain. Je re-essayerai sur de nouvelles bases.

    Réponse
    • 1 mars 2017 à 20 h 00 min
      Permalink

      Salut,
      Je recontre exactement le même soucis. Ce qui me surprend, c’est que Gnome 3.22 arrive à se connecter mais pas DAVDroid…

      Réponse
      • 1 mars 2017 à 20 h 47 min
        Permalink

        Bonsoir.
        En fait, mon smartphone possède une sur-couche MIUI sur Android (tél. Xiaomi) et avec MIUI, il faut autoriser (dans gestion du démarrage automatique) DavDroid à se synchroniser.
        Dans DavDroid, j’ai mis simplement comme paramètre : https://monsite.fr/remote.php/dav
        et ça a suffi pour qu’il trouve mes contacts et mon agenda.
        Par contre, dans le client NextCloud, j’ai mis comme adresse (de mémoire) : https://monsite.fr/remote.php/webdav et, ça fonctionne bien.

        Réponse
      • 1 mars 2017 à 22 h 50 min
        Permalink

        Pour moi sous LineageOS, j’ai ajouté l’user-agent de davdroid à la liste des incompatibles, et entré dans davdroid l’URL de l’agenda (le truc avec users/principals/monpseudo/calendars). Il a découvert l’agenda, les contacts et les tâches. Tout fonctionne sans aucun souci.

        Si tu as besoin de détails, fais signe 🙂

        Réponse
  • 4 mars 2017 à 16 h 32 min
    Permalink

    Tout est effectivement rentré en ordre sous Lineage OS 7.1 avec l’ajout de « /^DAVdroid/ ». Merci!
    Je vais pouvoir continuer ma déGooglisation tranquillement.

    Réponse
  • 9 mars 2017 à 17 h 11 min
    Permalink

    Merci pour ce tutoriel qui fonctionne bien avec Nextcloud 11.0.2 ! Je me permets d’ajouter mes quelques heures de recherches acharnées pour résoudre le problème de synchronisation avec DAVdroid.

    URL de compte : https://mondomaine.tld/dav/principals/users/monpseudo

    J’ai effectivement aussi dû ajouter <> à la ligne 533 de lib/base.php pour que la synchronisation fonctionne entre DAVdroid et Nextcloud sur un mutualisé OVH. (cf. pull request : https://github.com/nextcloud/server/pull/1593 )
    J’ai constaté l’erreur en cherchant dans les logs et j’ai trouvé l’erreur 503 suivante :
    <>

    Faire aussi attention à désactiver l’optimisation de batterie pour DAVdroid sur Android Marshmallow : https://davdroid.bitfire.at/faq/entry/sync-intervals-doze-mode/

    Réponse
  • 9 mars 2017 à 17 h 15 min
    Permalink

    Les guillemets ont été modérés pour l’erreur. Je reposte pour édition de mon premier commentaire si besoin. 😉

    PUT /remote.php/dav/calendars/monpseudo/moncalendrier/14…1b@sufficientlysecure.org.ics HTTP/1.1 503 25 – DAVdroid/1.4.0.3-ose (dav4android; okhttp3) Android/6.0.1

    Réponse
  • 14 mars 2017 à 17 h 40 min
    Permalink

    Bonjour à tous,

    Merci pour le tuto et les commentaires qui m’ont bien aidé.. Il me reste cependant un soucis.
    Mon serveur est en OVH mutu pro2014
    Mon client est en windows 10.
    Lorsque j’uploade un fichier > 200 M, je n’ai pas de soucis avec le client Windows via l’explorateur (jai modifié chunkSize dans nextcloud.cfg) mais ca coince avec l’interface web (edge me renvoi « connexion au serveur perdu » et chrome « Request entity too large »).
    Une idée ?
    Merci d’avance

    Réponse
    • 15 mars 2017 à 18 h 04 min
      Permalink

      J’ai le même hébergement, pro2014, et je ne vois pas ce que c’est que ton fichier nextcloud.cfg
      En revanche je viens d’avoir une cruelle déception : ça fait 3 jours que j’essaie de transférer un fichier de 1,5 Go sur le serveur et je n’y arrivais pas à cause d’un problème sur mon réseau (il semble qu’il y ait des travaux dans mon secteur). Mon débit était tombé à 1,5 mbits/s et la connexion était toujours coupée avant la fin du transfert. Aujourd’hui, j’arrive enfin au bout et, lorsque c’est terminé, (au bout de plus de 4 heures) j’ai le message : « unauthorized » ! et le fichier n’apparaît pas.
      J’ai mis [b]php_value upload_max_filesize 2G[/b] et [b]php_value post_max_size 2G [/b] dans mon .htaccess et un Quota à « illimité » dans mon profil NextCloud.
      Y-a-t-il une solution ?

      Réponse
      • 15 mars 2017 à 20 h 42 min
        Permalink

        Le fichier de configuration est lié au client desktop 🙂

        Pour l’upload via l’interface web, les deux valeurs post_max_size et upload_max_filesize sont inutiles sur un mutualisé OVH : ces valeurs sont définies par OVH et on ne peut malheureusement rien y faire.

        Pour ton gros fichier, tu as essayé via le client de bureau ? Ça devrait passer via webdav je pense, mais sans garantie. Je crois pourtant avoir uploadé de gros fichiers comme ça, genre 6-700Mo.

        Réponse
        • 15 mars 2017 à 21 h 03 min
          Permalink

          Merci pour la réponse.
          Je ne trouve pas, dans la doc OVH, les variables qui ont un effet ou non dans le .htaccess, le .user.ini ou autres. L’info doit être bien cachée.
          J’ai essayé de transférer mon fichier par ftp : il est effectivement bien sur le serveur (je le vois avec curlftps ou avec Filezilla) mais je ne le vois pas avec l’interface NextCloud. Je n’ai pas essayé avec le client bureau (je ne l’ai pas ré-installé depuis l’apparition de NextCloud) mais, en effet, ça me semble une bonne idée.
          Mais puisque le fichier est bien sur le serveur, je me demande s’il ne suffit pas de trifouiller une table mysql.

          Réponse
          • 17 mars 2017 à 9 h 39 min
            Permalink

            En gros, tu as cette doc ci :
            https://docs.ovh.com/fr/fr/web/hosting/modifier-lenvironnement-dexecution-de-mon-hebergement-web/

            Qui te donne un peu ce que tu peux customiser ou non. Le reste, c’est défini dans le php.ini du serveur, logiquement inaccessible et non modifiable localement (ça va à l’encontre du principe même de mutualisé).
            Si tu veux être sûr de la prise en compte ou non d’une instruction, fais-toi un petit script php pour afficher la variable, la modifier via ini_set() et l’afficher à nouveau. Tu sauras si c’est fait ou pas 😉

            Pour la question du FTP, effectivement, si tu ne passes pas par le client de synchro, ton fichier ne figure pas dans la base de données et n’est pas visible. Il faut lancer le scan à la main.
            Tu dois donc te connecter en SSH à ton mutualisé, et lancer la commande qui va bien. Sous Debian et consort, c’est

            1
            sudo -u www-data php occ files:scan --all -v

            depuis le répertoire d’installation de Nextcloud/ownCloud. Sur le mutu je pense que

            1
            php occ files:scan --all -v

            suffit.

            Un petit récap des principales opérations que tu peux être amené à effectuer en ligne de commande : https://www.c-rieger.de/using-nextclouds-command-line/

        • 16 mars 2017 à 8 h 55 min
          Permalink

          Merci Maxime pour ta réponse.
          Je vais donc passer par le client de bureau pour les gros fichiers. Dommage je trouvais le client web sexy…

          Réponse
  • 15 mars 2017 à 21 h 13 min
    Permalink

    Petite question, Maxime, puisque tu dis que tu utilises exclusivement DavDroid pour tes contacts et agendas (comme moi). Pour mes contacts, sur mon smartphone, (MI5S Plus sous Android 6.0.1 et MIUI 8.2) je n’arrive pas à créer de groupes : je ne peux créer que des groupes sur mon compte Google ou sur mon compte MIUI. Est-ce que toi, tu peux le faire ?

    Réponse
    • 17 mars 2017 à 9 h 42 min
      Permalink

      Alors, oui je peux le faire, du moins cela m’est proposé. Dans la configuration de ton compte DAVdroid, tu as bien mis la bonne option pour les groupes, parmi les 2 proposées ? Dans « Méthode pour les contacts de type groupe » il faut choisir « Les groupes sont des catégories pour chacun des contacts » d’après cette page : https://davdroid.bitfire.at/configuration/nextcloud/ (rubrique « DAVdroid setup »). Je n’ai pas poussé jusqu’à tester, mais si c’est au moment de la création que ça coince, je veux bien me prêter au jeu !

      Réponse
      • 17 mars 2017 à 16 h 34 min
        Permalink

        Bonsoir
        J’ai fait un essai avec 2 valeurs différentes de upload_max_filesize et
        post_max_size dans le .htaccess et le .user.ini.
        J’en ai déduit que c’est la valeur mise dans le .user.ini qui prime : j’ai mis 12G, valeur que je retrouve bien dans le phpinfo (). (À moins que ce soit la valeur la plus grande qui prime….)
        Je n’arrive pas à utiliser occ. Lorsque je tape une commande comme « php occ files:scan –all -v  » dans mon terminal ssh, j’obtiens systématiquement :
         »
        X-Powered-By: PHP/4.4.9
        Content-type: text/html

        Warning: main(__DIR__/console.php) [function.main]: failed to open stream: No such file or directory in /home/xxxxx/xxx/occ on line 11

        Fatal error: main() [function.require]: Failed opening required ‘__DIR__/console.php’ (include_path=’.:/usr/local/lib/php’) in /home/xxxxx/xxx/occ on line 11
        « 

        Réponse
        • 23 mars 2017 à 16 h 55 min
          Permalink

          C’est parce qu’il faut probablement remplacer « php » par « php5 » au minimum je pense, NC n’est pas compatible avec PHP4 🙂

          Réponse
          • 24 mars 2017 à 11 h 09 min
            Permalink

            Je viens seulement de comprendre comment lancer autrement que par la version php de défaut ; je le note pour qui chercherait comme moi : il faut remplacer php par
            /usr/local/php7.0/bin/php (remplacer php7.0) par la version voulue.
            Miracle : je retrouve synchronisés les fichiers transférés par ftp !

      • 17 mars 2017 à 17 h 17 min
        Permalink

        Bonsoir.
        Je crois que j’avais essayé les 2 possibilités dans « Méthode pour les contacts de type groupe » de DavDroid, mais comme la synchro ne se fait pas de suite, même avec le bouton « synchroniser », j’ai remis ce matin la valeur que tu préconises.
        Dans la liste de mes groupes, je ne peux toujours que créer un groupe dans mes contacts Google (ma liste est) vide ou dans mes contacts MIUI (où il n’y a qu’un nom) pas de groupe dans DavDroid.
        Et depuis un contact, si je veux le mettre dans un nouveau groupe, l’appli me dit que le nom existe déjà, quelque soit le nom que je mette. Mais ça , ça doit être un bogue.

        Réponse
        • 23 mars 2017 à 16 h 54 min
          Permalink

          Mh, étrange, je vais essayer…

          (Presque) rien à voir mais pour mémoire, dans le même esprit que l’user-agent de DAVdroid qui coince, j’ai voulu utiliser OpenTasks sous Android pour interagir avec l’application Tasks de Nextcloud, sans succès. J’ai fini par me dire que c’était probablement le même problème, et enregistrer les trames d’une tentative de synchro.

          Bingo ! En ajoutant l’user-agent de OpenTasks à la liste de ceux incompatible (dans lib/base.php), ça fonctionne directement.

          L’user-agent à ajouter est donc :

          1
          '/^CalDAV-Sync/',

          Ça servira bien à quelqu’un (au moins à moi à la prochaine màj de Nextcloud, quand ce sera à nouveau cassé 😀 )

          Réponse
  • 22 mars 2017 à 6 h 41 min
    Permalink

    J’ai bien suivi les différentes étapes pour l’installation sur mon mutilisé ovh 90plan mais jai comme erreur:
    Votre serveur web n’est pas correctement configuré pour la synchronisation de fichiers : l’interface WebDAV semble ne pas fonctionner.

    Je ne sais pas quoi faire. Avez vous une idée ?

    Réponse
  • 22 mars 2017 à 9 h 56 min
    Permalink

    Je crois que j’ai répondu trop vite : mon info n’est pas récente et ne semble plus d’actualité. À vérifier.

    Réponse
    • 22 mars 2017 à 11 h 56 min
      Permalink

      Oui ovh ne propose pas webDAV sinon j’essayerai pas d’installer owncloud 🙂

      Réponse
      • 23 mars 2017 à 16 h 50 min
        Permalink

        Exactement, ownCloud/Nextcloud embarquent SabreDAV, un serveur DAV, justement pour régler ce souci 😉

        Réponse
  • 22 mars 2017 à 21 h 09 min
    Permalink

    J’ai réussi à corriger tout les problème en faisant une nouvelle installation avec php 7.0 d’activé au lieu de 5.6
    puis j’ai fait les différentes étapes:
    – Étape 2a : les headers
    – Étape 2b : forcer HTTPS
    – Étape 2c : activer le cache
    – Étape 3 : installer le client sans péter sa synchro

    Et par miracle je n’ai plus aucune erreur. Même pas les 2 sités sur le site:
    – getenv(« PATH »
    – vérification d’intégrité

    Youpi

    Réponse
    • 22 mars 2017 à 21 h 18 min
      Permalink

      Heureux que tu aies réussi. Mais faudra m’expliquer comment tu as pu supprimer l’erreur sur le getenv(« PATH ») chez OVH. Ça me paraît de la magie !
      Le client, tu l’as installé sur quoi ? Linux, Windows ?

      Réponse
      • 22 mars 2017 à 21 h 59 min
        Permalink

        Je ne sais pas comment expliquer la disparition de getenv(« PATH »)
        J’ai installé le client sur Windows 10

        Réponse
        • 23 mars 2017 à 12 h 07 min
          Permalink

          Bonjour.
          Je reviens sur de vieux posts concernant l’erreur Zend OPcache dans le fichier log.
          Vous avez trouvé la solution ?
          L’erreur exacte est :
          « Zend OPcache API is restricted by « restrict_api » configuration directive at /home/mondomaine/monNC/lib/private/legacy/util.php#1349″

          Réponse
          • 23 mars 2017 à 16 h 49 min
            Permalink

            Toujours pas. C’est pas « grave » ici, c’est problématique pour d’autres apps que j’utilise, j’ai ouvert un ticket chez OVH, mais rien, on me demande des tests que j’ai déjà faits, ça gave.

            Apparemment ce module posait un souci, c’est compliqué, on a refusé de préciser ça :/

    • 27 mars 2017 à 9 h 26 min
      Permalink

      Rien ne vaut une mise à jour manuelle… le web updater ne fonctionne pas bien (voire pas du tout) sur les serveurs mutualisés d’ovh.

      Conseil : mettre tes fichiers en dehors du répertoire owncloud

      1 – Transfert du zip (téléchargé sur owncloud) sur ton serveur OVH avec filezilla
      2 – Sauvegarde de la BDD, du fichier de config et .htaccess
      3 – Renomme ton owncloud en owncloudback
      4 – Décompression du zip avec putty en ssh, ça va beaucoup plus vite qu’en ftp
      5 – Remplace dans le nouveau owncloud les fichiers htaccess et config par ceux sauvegardés
      6 – Va sur ta page owncloud pour la maj…et c’est tout
      7 – A la mise à jour suivante, suppression en ssh du owcloudback puis retour à l’étape 1

      Réponse
      • 27 mars 2017 à 9 h 35 min
        Permalink

        C’est à peu près la procédure que j’applique, sauf que sur mon mutualisé je n’ai pas d’accès ssh, et le zip est trop gros pour être dézippé via l’interface web ftp fourni par ovh. Il faut le dézipper avant le transfert qui du coup est très long 🙁

        Réponse
        • 27 mars 2017 à 9 h 56 min
          Permalink

          En mutualisé chez OVH, j’ai pourtant un accès SSH… Tu ne peux pas l’activer dans ton interface client ovh ?

          Réponse
          • 27 mars 2017 à 10 h 57 min
            Permalink

            Bonjour.
            En ce qui me concerne, ça a été la première fois (passage en NC 11.0.2) que l’update ne fonctionne pas (le mot de passe secret se trouve normalement dans le fichier de config) mais, de toute manière, je préfère une installation manuelle dans un nouveau répertoire, c’est le seul moyen d’être certain de ne pas garder de vieux fichiers obsolètes. Et, pour cela, je décompresse en local et fais le transfert par Filezilla; c’est assez long, mais on est pas obligé de rester devant l’écran.
            Dans mon manager OVH, je fais pointer un nouveau site vers le nouveau répertoire (par exemple Nextcloud2) et, lorsque j’ai bien testé et que tout fonctionne, je renomme mon ancien Nextcloud en NexcloudOld et mon nouveau Nexcloud2 en NextCloud. S’il y a un problème, je peux toujours refaire l’opération inverse (je fais la même chose avec la base de données)

          • 27 mars 2017 à 15 h 02 min
            Permalink

            Tu peux activer SSH en faisant la demande sur le forum, tu y trouveras les instructions et tout ce qui va bien. Même pour l’offre perso, que j’utilise.

            Pour le secret, il faut le régénérer ce secret. Tu peux créer uyn fichier PHP vierge et y coller :

            1
            <?php $password = trim(shell_exec("openssl rand -base64 48"));if(strlen($password) === 64) {$hash = password_hash($password, PASSWORD_DEFAULT) . "\n"; echo "Insert as \"updater.secret\": ".$hash; echo "The plaintext value is: ".$password."\n";}else{echo "Could not execute OpenSSL.\n";}; ?>

            Ensuite, accède à ce fichier directement depuis ton navigateur web.
            Ainsi, tu auras les deux valeurs, le hash et le texte, à garder dans un coin. Pour le hash, pense à le renseigner dans ton fichier de config 🙂
            Du coup, pas besoin de SSH pour ça ! 😉

          • 27 mars 2017 à 15 h 12 min
            Permalink

            Je ne savais pas qu’on pouvait activer ssh sur l’offre perso… Tu as un lien vers les posts du forum ?
            Merci pour le truc du fichier php ! Il faut le mettre à la racine du répertoire de Nextcloud ?

          • 30 mars 2017 à 10 h 07 min
            Permalink

            Oula non je n’ai plus les liens sous le coude, faudrait chercher, ou demander à @ovh_support_fr sur Twitter si tu as un compte.

            Pour le fichier PHP, à la racine de l’installation nextcloud c’est bien 🙂

          • 30 mars 2017 à 10 h 18 min
            Permalink

            Merci je vais chercher l’info ! Mise à jour réussi via le web updater. C’est quand même plus simple que la mise à jour manuelle 🙂

  • 29 mars 2017 à 11 h 01 min
    Permalink

    Bonjour.
    Au sujet de mon impossibilité de créer/utiliser des groupes dans DavDroid pour mes contacts, je viens de voir que la ligne ajoutée dans le fichier [b]lib/base.php[/b] à la liste incompatibleUserAgents
    avait disparu lors de la mise à jour. Je l’ai remise (‘/^DAVdroid/’) et, du coup, je retrouve à la fois mes groupes et ma synchro Agenda.

    Réponse
  • 12 avril 2017 à 21 h 31 min
    Permalink

    Merci beaucoup pour cet article qui m’a permis de résoudre facilement toutes les erreurs de mon installation de OwnCloud sur un hébergement mutualisé OVH !

    Réponse
  • 7 mai 2017 à 10 h 29 min
    Permalink

    Bonjour à tous.
    Je cherche désespérément comment utiliser convenablement un fichier html dans mes documents. Lorsque je clique dessus, il s’ouvre comme un fichier texte alors que je voudrais qu’il s’ouvre dans le navigateur, ou mieux, qu’il ouvre directement une adresse extérieure. Dans mon cas précis, j’ai une liste de fichiers pdf qui contiennent des partitions musicales, et je voudrais ajouter un lien vers un exemple d’interprétation sur Youtube (ou autre). Une solution serait de mettre directement le fichier vidéo ou audio, mais ça ferait un peu lourd. Croyez vous que cela soit possible ?

    Réponse

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *