CoolRaoul

Le password c'est celui qui a été saisi sur le NAS lors de la création du compte (il est conseillé au passage pour se simplifier la vie d'utiliser le même que celui attribué au compte windows correspondant). .

Faut avouer que la phrase "Je croyais que ce n'était plus qu'un mauvais souvenir" laissait entendre le contraire Normal puisque il n'y pas eu de modif dans /etc/passwd. Mieux vaut éviter scp pour le moment. en sftp root ne se connecte pas c'est normal Est-ce que les autres utilisateurs ont le droit d'utiliser sftp? dans leur profl, onglet "application", ftp doit être coché (en DSM 4 c'est la mème case qui contrôle ftp et sftp) On verra plus tard pour apache Pour que les comptes ait accès en partage windows faut au minimum qu'un dossier partagé qui leur est accessible ait été créé Le plus simple pour commencer est d'activer le partage "homes" (panneau de conf -> utilisateurs -> accueil utilisateur -> activer)

Apres avoir fait "vi ..." appuyer sur "G" (majuscule) ensuite "A" (toujours majuscule) taper la touche "<return>" (entrée) a ce moment coller les lignes "LoadModule ... " dans putty (Shift+Insert) taper à nouveau "<return>" taper la touche <esc> puis "ZZ" (encore en majuscule) en cas de doute, à tout moment taper <esc><esc> (deux fois) :q! permet de repartir au début (avant la commande "vi ...") Et terminer par /usr/syno/sbin/synoservicecfg --restart httpd-user

SFTP marchait avant pour ces comptes? Il est strictement impossible que la connexion via wincsp en mode "scp" ait marché jusqu'ici sans avoir touché au "/etc/passwd" (sauf en utilisant le user "root" avec le mot de passe du compte "admin") Faudrait préciser avec plus de détails ce qui marchait et ce qui ne marche plus. (quelle methode de connexion, sftp ou autre).

Il est fort possible que ce soit un des clients PC qui merdoie. La seule solution me semble-t-il pour avancer et de tous les stopper puis le relancer un par un. Si ce n'est pas possible je n'ai malheureusement pas d'autre procédure à proposer.

Ci dessus il est question de CloudStation Je me demande si il ne serait pas temps de faire un sujet distinct par problème sinon on va avoir du mal à suivre. (ou bien SVP faire l'effort de citer le message auquel on répond)

Et qu'est-ce que ça donne inversement en stoppant le client PC et laissant le package tourner sur le NAS? Je ne me souviens pas si le client PC se met à jour automatiquement, peut-être regarder de ce coté également. Peut-être aussi que la consultation du fichier log de cloudstation sur le Syno (/var/log/cstn/syncfolder.log) pourrrait aider à trouver des pistes

J'avais oublié: Pour que scp fonctionne faut avoir modifié le shell du compte utilisateur dans /etc/passwd sur le syno: est-ce que ça à été fait? (mais mieux vaut faire du sftp plutôt, qui n'a pas cette contrainte) Quand à ftp, mis à part le fait que service ftp doive être activé (mais ça va de soit) encore faut il que le compte soit autorisé en connexion ftp entrante (privilèges d'application dans les propriétés du compte).

Je ne suis pas sur de comprendre cette phrase: initialement tu parlais de "clients" au pluriel et il maintenant question d'un login (singulier). En outre quand tu ecris "sans accent ça ne fonctionne pas non plus" faut- il comprendre que tu utilises un *autre* compte syno, différent du premier et sans accents, ou que tu essaie de te connecter sur le même compte en n'utilisant pas les accents? Faudrait faire un test avec un login non admin et sans caractères spéciaux

Vu qu'aucune documentation ne semble disponible, ça n'est pas prés de changer Je l'ai téléchargé, ca contient au contraire tout une arborescence de librairies (/usr/syno/lib), includes(/usr/syno/include) et binaires (/usr/syno/bin) Plus de 600 megas compressé quand même. Hélas, j'ai eu la flemme (j'ai honte ) d'apprendre à utiliser spksrc et je me suis bâti un petit environnement de cross compil perso pour mon archi, s'appuyant aussi sur la toolchain officielle. Voila pourquoi je me demandais si je dois migrer sur la version de toolchain étiquetée "5.0 beta" ou si une définitive va bientôt être diffusée. (cela dit apparemment la compatibilité ascendante me semble OK, donc il n'y a pas le feu)

Avant de tout de suite envisager des solutions radicales, serait-il possible de commencer par vérifier si le login/password d'un des comptes non admin est également refusé lors d'une connexion http, directement sur le GUI DSM, histoire de cibler un peu mieux ou se trouve le problème. Préciser quelle est la version de DSM utilisée aussi

Voulant mettre à jour mon espace de cross compilation par rapport a la DSM 5 je m’aperçois que sur l'espace "Synology NAS GPL Source" de Sourceforge les toolchain les plus récents sont dans un dossier toujours affublés de l'attribut "beta" A coté de ça je vois apparaître un répertoire "toolkit" mais donc la structure du contenu ne correspond pas à la documentation existante (http://ukdl.synology.com/download/ds/userguide/DSM_Developer_Guide.pdf) Bref je suis un peu pommé.. Si une bonne âme voulais bien me remettre dans le droit chemin **EDIT** Ma mémoire me faisait défaut: wayback archive m'a permis de constater que le toolkit existe depuis un bout de temps Reste ma question sur l'arrivée de la toolchain "non beta" et sur l'usage/documentation de ce toolkit Merci d'avance.

Je n'ai pas dit ça! Via PhotoStation on peut gérer les droits aussi finement que l'on veux (il a sa propre gestion de droits intégrée). Par contre il faut alors astreindre les utilisateurs du NAS à utiliser *exclusivement* photostation pour manipuler les photos (en limitant globalement les acces au partage "Photo" au seuls administrateurs : panneau de configuration -> dossier partagé -> photo -> modifier -> permission) L'autre approche est de ne pas utiliser Photo Station et choisir un autre dossier partagé que "photo" pour stocker ses photos.

Pour ceux que ça intéresse le chemin du doc à changé, c'est ici maintenant: http://download.synology.com/download//Document/FAQ/Synology_Download_Station_Official_API_V3.pdf

C'est comme cela que fonctionne le dossier "photo". Il n'est pas vraiment prévu pour être accédé autrement que via PhotoStation (qui a sa propre gestion de droits). Si on veut gérer les droits directement en acces direct (partage windows, filestation, etc ... ) à sa convenance il faut utiliser un autre dossier. (mais on ne pourra plus utiliser PhotoStation).

Je viens de m'apercevoir que Synology avait oublié de fournir avec DSM 5 le contenu complet du répertoire "zoneinfo" ("/usr/share/zoneinfo"). La conséquence est que de nombreuses commandes se retrouvent à récupérer des heures UTC car elles n'ont pas accès à la description de la timezone déclarée dans la variable TZ (qui se définit dans les options régionales, onglet "temps", rubrique "fuseau horaire" du panneau de configuration) Je me demande d'ailleurs au passage si cela n'aurait pas d'impact possible sur certains scripts PHP. Coup de pot, la distribution pgsql incluse dans DSM comprend sa propre copie du dossier zoneinfo. Ci dessous un petit script (à exécuter une seule fois et après chaque upgrade) qui résout le problème via des liens symboliques; #!/bin/ash PATH="/bin:/usr/bin" PGSQLDIR="/usr/share/pgsql-8.3" # sera sans doute à modifier dans les releases à venir cd $PGSQLDIR/share/timezone || exit 1 for tzdir in * do [ -d "$tzdir" ] || continue tzsysdir="/usr/share/zoneinfo/$tzdir" [ -e "$tzsysdir" ] && continue echo "fixing $tzdir" >&2 ln -s "$PWD/$tzdir" "$tzsysdir" done exit Résultat Avant: > echo $TZ Europe/Brussels > /bin/date -u Sun Mar 16 08:49:59 UTC 2014 > /bin/date Sun Mar 16 08:50:01 Europe 2014 # <-- GMT Apres: > /bin/date -u Sun Mar 16 08:50:32 UTC 2014 > /bin/date Sun Mar 16 09:50:33 CET 2014 # <- timezone bien prise en compte maintenant ***EDIT*** Je réalise que tout ce qui précède n'est pas forcément nécessaire: si le contenu de ma variable TZ était au format "<continent>/<pays>", c'était suite à une ancienne l'installation d'un package Java qui avait ajouté cette définition dans le ".profile" de root. Bien que le package ait été désinstallé cette définition était restée. Apres l'avoir supprimé, je me retrouvé bien avec un TZ défini "à l'ancienne" ("CET-1CEST,M3.5.0,M10.5.0/3" pour moi) qui n'utilise donc pas les fichiers "zoneinfo"

Tu peux "monter" ("mapper" si tu préfère ) des dossiers partagés du 2eme NAS dans des dossiers existants vides du NAS auquel tu es connecté via filestation. Dans file station utiliser le menu "outils -> monter le dossier distant"

Ah oui, bien vu En DSM 4.X les fichiers de conf apache étaient générées dynamiquement lors du démarrage et cette méthode ne s'appliquait pas ce qui explique que je n'y ai pas pensé.

Ou, plus rapide (puisque connecté en shell) le relancer avec la commande : /usr/syno/sbin/synoservicecfg --restart httpd-user

me semble bien avoir écris "il y a des fils à ce sujet dans le forum" Suffisait de chercher un peu, tiens voici: Mais je te conseille plutôt la deuxième solution (filtrage dans le firewall) bien plus facile à implémenter

On l'a quand même échappé belle: dans la beta certains étaient carrément absent du répertoire "modules". Si c'était resté comme ça la on aurait vraiment emm*

Allez, histoire d'en revenir au fondamentaux En DSM 4, la commande permettant de redémarrer le service web "user" ("/usr/syno/etc/rc.d/S97apache-user.sh restart") affichait clairement les erreurs a l'écran (dans le cas d'erreurs de syntaxe dans les fichiers de conf apache) Maintenant, que le script apache-user à disparu de rc.d, ne reste que "/usr/syno/sbin/synoservicecfg --restart httpd-user" mais on se retrouve aveugle. Le premier qui trouve une solution pour faire s'afficher les erreurs aura droit à toute ma gratitude

J'étais en train de te répondre sur cet autre fil avec la solution mais, le temps de trouver les références, je me suis fait doubler.

En fait c'est toujours supporté mais les modules requis ne sont plus chargés par défaut par apache Suffit de rajouter les bonnes lignes "loadmodule" dans le fichier "/etc/httpd/conf/httpd.conf-user" (ou mieux dans in fichier perso inclus par ce dernier) Voir ici: http://forum.synology.com/enu/viewtopic.php?f=232&t=79801&start=15#p308755 **EDIT** doublon!

C'est le port ssh par défaut qui est le plus attaqué. Utiliser un autre no de port entrant que le 22 (suffit de modifier la règle de redirection de port dans le routeur) est particulièrement efficace pour diminuer de façon drastique les attaques (je peux en témoigner) Par contre après ça, si on veut que la sauvegarde externe continue à effectuer il y aura des modifs de conf à faire sur l'autre NAS (il y a des fils à ce sujet dans le forum) Autre possibilité: dans la mesure ou l'ouverture de ce port est exclusivement réservée à la sauvegarde d'un NAS externe, ajouter dans le firewall du Syno une règle autorisant en entrée l'IP externe ce dernier (pou peu qu'il s'agisse d'une IP fixe) suivie d'une règle bloquant le port SSH pour toutes les IP et tu sera vraiment tranquille.