guygox

Bonjour, Sur mon Syno en DSM 6, je rencontre un problème avec les partages. Quand je suis en SSH en admin, impossible de faire un cd NomDossier, j'ai un accès denied, avec File Station ou les partages par le réseau pas de problème. L'inspecteur de permissions me dit que j'ai bien le contrôle total. Mais en allant dans "Permissions avancées", je n'ai pas le menu "Autorisation de partage avancées". Mais je l'ai sur d'autres dossiers... Et pourtant les groupes ayant les droits sont les mêmes. Je ne vois pas du tout ce que je peux faire, si quelqu'un a une idée... Merci !

Bonjour, Je possède deux RS3614xs+ un avec 16,2To/25,3To, l'autre de 32,6To..plein Or il y a peu de changement sur le NAS que je backup (en plus je ne sauvegarde pas tous les dossiers partagés), tout va bien pendant un certain temps : Je n'ai que quelques gigas par jour. Je ne regarde pas une semaine et je me retrouve avec l'espace du NAS de sauvegarde plein. Pourtant la fonction "Activer la sauvegarde au niveau blocs" est activée. ça peut bien marcher pendant 1 mois et après problème. J'ai également augmenter l'intervalle de sauvegarde, toutes les 6 heures. Je garde 3 mois de rétention soit le minimum. Je ne sais pas sur quelle sauvegarde ça merde en général. Et si je fais un "du -chs" sur le Synology ça prend une demi-journée (sans rire). J'ai juste une piste, j'en ai une dans le lot partielle, et du coup je ne sais pas vraiment comment fonctionne la sauvegarde : Prend il le différentiel de la dernière plus des hardlinks ou des hardlinks pour chaque fichier... D'autre part, supprimer sous TimeBackup les dossiers ne me supprime pas le dossier sur le NAS. Bref si quelqu'un a une piste, car là je n'ai plus de sauvegarde et à part repartir à zéro (mais comme par hasars, ils vont me demander de restaurer). Et je ne peux me permettre de faire ça tous les 15 jours. Merci !

Je vais envoyer ça !

Comment faire pour remonter ça ? J avais trouve la solution sur un forum debian. Suite a une mise a jour openssh plusieurs utilisateurs avaient le même problème. Sous google en tapant "ssh synology problem mtu" j ai eu quelques trucs en rapport également. Mais à part la baisser, personne n avait de solution.

J'ai réussi à faire fonctionner le SSH et la sauvegarde en modifiant la MTU qui était en jumbo à 9000. Le truc c est que mon ancien est aussi en jumbo avec un trunk LACP et pas d eproblème. (mes switchs sont en jumbo aussi). Une idée d'où ça provient?

J'ai mis à jour en update 3...redémarré les équipements sans succès...

Nas1> ssh -v admin@nas-samka4B OpenSSH_6.6, OpenSSL 1.0.1k-fips 8 Jan 2015 debug1: Connecting to nas-samka4b [192.168.51.44] port 22. debug1: Connection established. debug1: identity file /var/services/homes/admin/.ssh/id_rsa type -1 debug1: identity file /var/services/homes/admin/.ssh/id_rsa-cert type -1 debug1: identity file /var/services/homes/admin/.ssh/id_dsa type -1 debug1: identity file /var/services/homes/admin/.ssh/id_dsa-cert type -1 debug1: identity file /var/services/homes/admin/.ssh/id_ecdsa type 3 debug1: identity file /var/services/homes/admin/.ssh/id_ecdsa-cert type -1 debug1: identity file /var/services/homes/admin/.ssh/id_ed25519 type -1 debug1: identity file /var/services/homes/admin/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.6p2-hpn14v4 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6p2-hpn14v4 debug1: match: OpenSSH_6.6p2-hpn14v4 pat OpenSSH* compat 0x04000000 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: AUTH STATE IS 0 debug1: REQUESTED ENC.NAME is 'aes128-ctr' debug1: kex: server->client aes128-ctr umac-64-etm@openssh.com none debug1: REQUESTED ENC.NAME is 'aes128-ctr' debug1: kex: client->server aes128-ctr umac-64-etm@openssh.com none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

Je viens de tester.. Pas plus de succès. Mais je n'ai pas redémarré le service SSH. Ma commande ne marche plus (/usr/syno/etc.defaults/rc.d/S95sshd.sh restart et dans le dossier rc.d je ne vois rien ressemblant au SSH). Du coup je suis oblmigé de les redémarrer ce soir. Je posterai après redémarrage (sauf s'il n est pas utile de redémarrer le service).

> ssh -vv admin@nas OpenSSH_6.6, OpenSSL 1.0.1k-fips 8 Jan 2015 debug2: ssh_connect: needpriv 0 debug1: Connecting to nas [192.168.51.44] port 22. debug1: Connection established. debug1: identity file /var/services/homes/admin/.ssh/id_rsa type -1 debug1: identity file /var/services/homes/admin/.ssh/id_rsa-cert type -1 debug1: identity file /var/services/homes/admin/.ssh/id_dsa type -1 debug1: identity file /var/services/homes/admin/.ssh/id_dsa-cert type -1 debug1: identity file /var/services/homes/admin/.ssh/id_ecdsa type -1 debug1: identity file /var/services/homes/admin/.ssh/id_ecdsa-cert type -1 debug1: identity file /var/services/homes/admin/.ssh/id_ed25519 type -1 debug1: identity file /var/services/homes/admin/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.6p2-hpn14v4 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6p2-hpn14v4 debug1: match: OpenSSH_6.6p2-hpn14v4 pat OpenSSH* compat 0x04000000 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: AUTH STATE IS 0 debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: kex_parse_kexinit: none,zlib@openssh.com debug2: kex_parse_kexinit: none,zlib@openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: setup umac-64-etm@openssh.com debug1: REQUESTED ENC.NAME is 'aes128-ctr' debug1: kex: server->client aes128-ctr umac-64-etm@openssh.com none debug2: mac_setup: setup umac-64-etm@openssh.com debug1: REQUESTED ENC.NAME is 'aes128-ctr' debug1: kex: client->server aes128-ctr umac-64-etm@openssh.com none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REP

Rien de rien... de base. Je peux essayer de mettre à jour en Update 3 qui est sortie il y a quelques jours mais je ne suis pas sûr que ça touche au ssh...

Bonjour Merci de la réponse. Côté firewall, rien (et j'y arrive d'ailleurs dans le LAN). A part modifier les conf de ssh_config mais j'ai peur que ça saute à chaque mise à jour. Voici le résultat du ssh -v : Nas1> ssh -v admin@192.168.51.44 OpenSSH_6.6, OpenSSL 1.0.1k-fips 8 Jan 2015 debug1: Connecting to nas [192.168.51.44] port 22. debug1: Connection established. debug1: identity file /var/services/homes/admin/.ssh/id_rsa type -1 debug1: identity file /var/services/homes/admin/.ssh/id_rsa-cert type -1 debug1: identity file /var/services/homes/admin/.ssh/id_dsa type -1 debug1: identity file /var/services/homes/admin/.ssh/id_dsa-cert type -1 debug1: identity file /var/services/homes/admin/.ssh/id_ecdsa type -1 debug1: identity file /var/services/homes/admin/.ssh/id_ecdsa-cert type -1 debug1: identity file /var/services/homes/admin/.ssh/id_ed25519 type -1 debug1: identity file /var/services/homes/admin/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.6p2-hpn14v4 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6p2-hpn14v4 debug1: match: OpenSSH_6.6p2-hpn14v4 pat OpenSSH* compat 0x04000000 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: AUTH STATE IS 0 debug1: REQUESTED ENC.NAME is 'aes128-ctr' debug1: kex: server->client aes128-ctr umac-64-etm@openssh.com none debug1: REQUESTED ENC.NAME is 'aes128-ctr' debug1: kex: client->server aes128-ctr umac-64-etm@openssh.com none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

Bonjour, Je rencontre un problème avec le paquet "Sauvegarde et réplication" pour faire de la sauvegarde entre deux Synology sur le même LAN. Toutes les étapes de configuration du paramétrage passent (ILe NAS à sauvegarder voit bien mon dossier en face, je sélectionen bien mes partages à sauvegarder) mais ensuite il y a systématiquement un échec. J'ai essayé de réduire le nombre de dossiers sauvegardés et c'est pareil. Je suis en DSM 5.1.5022 Update 2. Chose "remarquable". Je n'arrive pas à faire de SSH de NAS à NAS. Alors que depuis un PC vers ces deux NAS, ça marche. Que depuis n'importe lequel des NAS je peux faire du SSH vers un autre serveur ssh (linux) mais d'aucun des deux je n'arrive à avoir le prompt du password quand je veux faire du SSH de syno à Syno. Je pense que c'est lié mais je ne vois pas pourquoi ça ne marche pas. Une idée?? alors j'ai lu à droite à gauche que ça merdait en DSM 5 et qu'il fallait être en 5. Mais j'ai d'autres clients avec des Syno DSM 5 avec lesquels ça marche Merci à vous !

personne???

Non même pas... et puis ça marche ensuite... Et c'est vraiment chaint car les users le sont...

Bonjour, Sur un Synology en dernière version DSM, je rencontre ponctuellement des problèmes d'écriture/renommage/suppression. Les cas les plus remontés sont le renommage. Les utilisateurs montent le partage en samba (afp me posait des droits sur la propagation des permissions, je n'ai jamais su si c'était un problème MAC suivant les versions d'OS ou Syno ). Les ACL sont activées (droits particuliers sous certains sous dossiers). Lorsqu'un utilisateur veut modifier un dossier il a une erreur. Lorsque je regarde avec lui sans changer de compte utilisateur, ça fonctionne toujours du premier coup mais je les crois (plusieurs à me remonter ce problème). J'ai beau reforcer les héritages pareil le lendemain. Je ne sais pas pourquoi les dossiers se verrouillent surtout qu'apparemment aucun autre utilisateur n'est censé afficher ou modifier un élément dans ce sous répertoire à ce moment (pas vérifié mais question de probabilités). Si vous avez des pistes pour analyser ou résoudre le problème de verrouillage ou une solution sur les problèmes d'héritage avec afp et les acl Syno. Je pensais sinon utiliser un Mac en XServ monter le syno en ISCSI, je pense que ça résolerait tous les problèmes mais il me faudra stocker les dossiers temporairement, reconfigurer mon stockage, recréer tous mes users sur le mac, repasser sur les postes clients pour vérifier les montages. ça me parait fastidieux. Qu'en pensez vous?

Par contre généralement les arrêts je les fais en CLI par l'interface Web je n'ai pas trouvé à part en se connectant sur un mobile. Là il y a un menu services vachement bien fait.

bonjour, Lorsque je change le quota d'un utilisateur (pour un volume donné ou sont stockés les Time Machine des MAC), le time machien sur le poste voit toujours l'ancien même après redémarrage du poste. Seul le redémarrage des services réseau AFP/SMB (ou le redémarrage du boitier bien entendu) me permet de mettre à jour apparemment ce quota. J'ai tenté sur plusieurs jours. Connaissez une solution pour éviter de relancer les services (embêtant sur le système en production)? Une commande a exécuter pour forcer cette MAJ? Merci

bonjour Je possède un 1813+ avec donc 4 liens ethernet giga que j'ai laggué/trunké sur un switch qui supporte le LACP. Je souhaiterais faire des tests de virtualisation, je possède actuellement une grosse baie avec du 10gbe, des disques SATA et SSD. Je ne m'attends pas à trouve ren ce synology une solution de remplacement mais savoir si pour une PME avec quelques VM Windows si ça tiendrai. Je souhaiterais donc avoir un retour d'expérience si quelqu'un a testé?? Et si oui avec combien de machines virtuelles? Leurs rôles (messagerie, SQL)? Si ça tient la charge ? Et comment faire de la réplication inter-baie? combien d'utilisateurs? Merci à vous !

Bonjour, Est il possible de mettre les disques d'un 411+ HS dans un 412+ sans perdre les données? J'ai testé mais il me dit "Configuration perdue". J'hésite à rebalancer le DSM dessus pour ne pas perdre les données. D'après le forum j'ai vu que sur le même matos c'était testable et qu'apparemment les datas ne disparaissaient pas. Que me conseillez-vous?

Si lors de la selection des partages on choisi genre 3 versions, la sauvegarde nécessite 3 fois le stockage source ou alors c'est du différentiel?

Bonjour sur un Syno 1711+ , j'ai crée des partages et activé Samba et AFP. J'utilise également les ACL sur les dossiers. Sur le samba : Si un utilisateur créé des dossiers ou fichiers, les ACL sur les les sous dossiers, fichiers sont bien héritées. En AFP : PAs d'héritage de l'ACL, les droits sur les éléments ajoutés ont les permissions de l'utilisateur qui les dépose. JE ferai bien bosser tout le monde en SMB/CIFS mais j'ai des MAC et je ne sais pas pourquoi mais sous 10.5.8 ou 10.6.8 avec Adobe CS4, ça plante (reboot obligatoire si on souhate rouvrir le soft qui plante completement) souvent au moment de l'enregistrement sans raison particulière et ça sur tout le parc (pas de problème réseau, pas de coupure du NAS) et je n'arrive pas à déterminer si cela vient des versions samba client serveur , Adobe... (si quelqu'un a une piste ou un moyen de determiner d'où cela vient). Mais mon problème est de comprendre pourquoi les ACL ne sont pas héritées en AFP... MErci à vous

Bonjour, J'ai activé l'option corbeille CIFS. Mon client souhaite que les utilisateurs n'aient pas accès au contenu (pour ne pas intentionnelement supprimer). J'ai donc coché l'option restereindre aux administrateurs. Plusieurs partageent sont créés. Sur chacun, une personne est chargée d'administrer. Le client veut que cette personne ait accès à la corbeille mais pas aux autres partages ni aux autres corbeilles ni à l'admin de l'équipement. Est-ce possible? J'ai ajouté à la main dans les propriétés des acl l'utilisateur pour chaque partage. Ce qui je pense fonctionne mais je crains qu'en cas de MAJ de l'équipement ou de check disk ou même redémarrage ça saute (je n'ai pas pu redémarré l'équipement). Quelqu'un utilise cette fonctionnalité et à un retour à me faire??

Justement le problème c'est que le dossier parent a des droits différents, il y a après des sous-dossiers sur lesquels je dois dans ce cas manuellement modifier les droits... Par contre si je mets rendres les permissions implicites et comme permissions dans Ecriture, supprimer des sous-dossiers et des fichiers, mais pas supprimer. Si un user créé des dossiers, ces derniers héritant des droits, pourrons t'ils être supprimés (sachant que si on fait un clic droit sur le dossier créé dans File Station, permission, on voit logiquement que la case supprimer est décocher donc pour moi à priori il ne pourra être supprimé). MAis dans ce cas comment utiliser cette option? Faut il dans les sous dossier tout le temps couper l'héritage??? Merci

Pour les droits pour moi s'il y a pas de "refusé" si un utilisateur a les droits d'écriture en appartenant au groupe1 et les drits de lecture au groupe2 il a lecture+ecriture ? Par contre si un groupe a "Refuser" et que j'ajoute un utilisateur de ce groupe avec les droits, "Refuser" sera prioritaire. Je me trompe? Mais dans mon cas, les utilisateurs ayant le droit d'acceder à ce partage sont bien distincts. Mon porblème est qu equand je le copie. Les droits antérieurs sont appliqués à savoir lecture seule pour groupe2 et lecture/ecriture pour le groupe1... Les droits définis sur le template sont donc modifiés.

Effectivement en passant de DSM 3.2 à la 4 je vois correctement mes ACL mais je ne peux que ajouter ou enlever des permissions à des users à partir d'un poste Windows mais pas ajouter de nouveaux users (il me redemande de m'authenitifer il accepte mais ne me renvoie pas la liste des users du Syno alors que je suis bien dans le même groupe de travail...). Mais je peux sous FileStation les modifier donc pour l'instant à moins que vous ayez une solution rapide, ça n'est pas grave. Par contre les utilisateurs veulent mettre une arbo un peu particuliere du type : Dossier1-SousDossiers1-NomdeClient (Nom de Client est variable suivant le client). No mde client continet d'autres sous dossiers. Le dossier1 doit etre en lecture/ecrtiure pour le groupe1 et en lecture seule pour le groupe2. Il veulent dans ce dossier crééer un répertoire de type template qui contient l'arbo d'un dossier avec les bons droits. Sur le template j'ai bien modifier les droits comme voulus mais des que je le copie/Colle, la copie du dossier réhérite des droits. J'ai essayé avec un user ayant les droits pour copier le dossier mais sans la modif/lecture des attribue, non propriétaire du dossier mais sans succès. Vous avez une idée des droits corrects à mettre pour que cela fonctionne? Sur le SousDossier1 j'ai coupé l'héritage des droits et les ai remis à la main pour tester, j'ai essayé en modifiant le fichier /usr/syno/etc/smb.conf en mettant inhertit permissions = no ... MAis encore une fois sans effet.