CoolRaoul

Il n'existe pas de methode pour changer le groupe *principal* avec l'interface d'admin DSM. Si tu as modifié /etc/passwd à la main n'oublie pas que ce n'est pas supporté par Synology Par contre on peut librement ajouter des groupes supplémentaires Ne pas oublier que, comme dit plus haut, les utilisateurs ne sont pas limités à un groupe unique un .profile ne s'exécute que dans le cas de sessions shell interactive, dans tous les autres cas il est ignoré (et ce n'est pas spécifique à DSM, c'est comme ça sous tous les systèmes Unix depuis la nuit des temps. Pour la raison de non exécution du profile déjà expliquée. Pour gérer les droits par défaut (des nouveaux fichiers et dossier) faut migrer le partage pour utiliser les ACL Par contre, c'est autrement plus complexe. Je te conseille de créer un partage de test pour jouer avec et expérimenter avant de convertir tes partages existants. Mais tu devrais sans doute parvenir à tes fins en modifiant globalement les droits du partage: donner acces lecture/écriture W aux utilisateurs du groupe "nous" et lecture seule à ceux du groupe "users". Même si les droits unix sont 777, ce sont les droits du partage qui prévalent (sauf en shell, mais par défaut seul "root" à droit a se connecter ainsi) Sinon tu ne coupera pas à la solution ACL

Oui, j'ai bien compris ça, sinon il serait impossible de se connecter au NAS pour l'administrer C'est pourquoi je pense qu'il y a un problème plus tordu et que seul le support pourra résoudre (A moins que la description de ce qui s'affiche -"il n'y a rien"- soit incomplète mais faudrait voir une copie d’écran alors.) La page HDD/SDD ne peut pas être vide (sauf le cas spécial des modèles USB Station peut-être).

Il est possible qu'il soit bien lancé au démarrage mais se termine en erreur car faisant référence à des choses devenues inexistantes en DSM5. Est-ce qu'il fonctionne quand on le lance à la main? Est-ce qu'il respecte bien les conditions (le nom se termine en ".sh", son mode est exécutable) ? La ligne d'en-tête pointe-t-elle bien vers un shell existant ("#! /bin/sh" ou "#! /bin/ash") ?

Qu'il n'y ait rien dans cette zone voudrait normalement dire qu'aucun disque physique n'a été détecté. Mais dans ce cas DSM n'aurait même pas pu être installé (il lui faut bien au moins un disque) La j'avoue ne plus savoir ce qui se passe. Faut contacter le support.

Problème je ne peux pas reproduire ta config Je pense qu'en allant dans "HDD/SDD" tu devrais découvrir comment est détecté ce nouveau disque que tu viens d'ajouter.

Si tu ne trouves pas, c'est probablement que tu dois chercher dans le panneau de configuration alors qu'il faut passer par le "gestionnaire de stockage" qui est une application séparée (dans le menu principal)

Comme service d'hébergement d'images j'utilise imgur Et comme outil de capture (avec upload intégré sur imgur et d'autres) je conseille GreenShot ou ShareX (interface plus touffue et complexe pour ce dernier mais meilleure compatibilité avec les proxies) Armé ainsi, le délai entre le "PrintScreen" et la visibilité de l'image dans un post sur le forum est à peine de quelques secondes (annotations inclues). CoolRaoul, le plus rapide uploader de screenshots à l'ouest du Pecos

Je viens de passer le cap à l'instant! En espérant de continuer à tenir le rythme sans fléchir et à votre santé à tous (on est dans le bar non?)

Non, en plus du "chmod +x" et du suffixe .sh le fait qu'il soit dans ce dossier est suffisant Si tu veux avoir une trace que tout se passe bien ajoute la ligne suivante en début de script (avant le case) [ -t 0 ] || exec >/tmp/script_mount.log 2>&1 Ce qui aura pour effet de rediriger sortie et erreur standard quand l'entrée standard n'est pas un terminal (et donc lors du boot mais pas quand tu le testes en ligne de commande) Normalement le fichier .log ne devrait rien contenir sauf en cas d'erreur.

manque juste une ligne "esac" avant "exit" pour fermer le "case" Ensuite, tu peux déja le tester en ligne de commande, en tapant: /usr/local/etc/rc.d/script_mount.sh stop et /usr/local/etc/rc.d/script_mount.sh start

Faut lancer VideoStation à partir du compte "admin" ou d'un compte faisant partie du groupes des administrateurs. Là on dispose du bouton : qui va permettre de modifier les caractéristiques des dossiers: reste plus qu'a choisir la langue des infos récupérées:

/etc/fstab est géré par DSM et ne doit pas être modifié Pour monter automatiquement des volumes au boot le mieux est de passer par un script shell de startup avec les commandes "mount" qui vont bien Le mettre dans "/usr/local/etc/rc.d" (son nom peut être quelconque mais doit avoir le suffixe ".sh", il sera invoqué au boot avec $1 = "start" et au shutdown avec $1 = "stop" (et ne pas oublier le "chmod +x")

"Windaube" enfin... tapes la commande: head -15 /etc/ssh/sshd_config et donne nous le résultat (et ne t'emm* pas avec un screenshot, un copier/coller texte suffira) **EDIT** Apparemment il y a un "$" en tete de la ligne 13, suffit de le supprimer

Oh put... tu as édité le fichier avec un éditeur sous windows Il est tout foireux... un instant je reviens ...

Sans nous donner le texte du message d'erreur on peut difficilement t'aider du sais

Ben oui, déja tu sera protégé par ta box (les connexions entrantes sur les ports non redirigés sont ignorées) et en deuxième niveau par le firewall du NAS (avec la possibilité de mettre des règles plus "fines" sur les ports ouverts) **EDIT** Il y a quand même une possibilité,avec un fournisseur d'acces VPN, d'avoir une sécurité à peu prés équivalente à celle d'une box sans redirections, c'est si ce dernier t'affecte une IP "NATtée" (non publique) NB: je ne sait pas si ce genre d'offre VPN existe. L'inconvénient est que cela rendra impossible l'utilisation de protocoles P2P. Autre possibilité, si l'IP affectée au tunnel VPN est exclusivement IPV6, tu sera accessible mais bien moins visible.

Si tu te préoccupe de sécurité faut que tu saches que le firewall de DSM ignore l'interface IP virtuelle établie par son client VPN (à moins que ça ait changé depuis DSM 5 mais je n'ai pas lu cette information) Ce qui revient à dire que, par ce tuyau, le NAS est en quelque sorte "a poil" sur internet. Donc, pour ce qui est de la sécurité c'est pas vraiment ça .. En effet, le client VPN de DSM est en priorité conçu pour relier celui-là un autre réseau *local* de confiance via internet et le firewall est inutile dans ce cas. En l'utilisant en connexion avec un fournisseur public d’accès VPN faut pas espérer être en sécurité, bien au contraire. Les seuls usages du type d'architecture décrit ici sont soit pour faire des choses pas toujours légales sans se faire repérer, soit pour accéder à des services qui utilisent des filtres de type geoIP bloquant ton pays d'origine (comme NetFlix) . Dans tous les cas, vu que ton NAS va se retrouver en mode "open bar" sur le net, autant faire abstraction des considérations de sécurité et choisir tout simplement le protocole qui pose le moins de problème avec la BOX.

Si ta seedbox le supporte, en ligne de commande, tu peux aussi utiliser sftp (peut-être plus simple que wget).. ***EDIT*** Ou même directement ssh, avec des truc du genre: ssh -i <chemin_de_ma_cle_privée_sans_passphrase> seedboxuser@maseedbox "cd <rep> ; tar cf - <fichier>" | tar -C <rep_local> -xf - Ou encore mieux, rsync!

La solution wget, c'est parce qu'a été ajouté la contrainte de ne pas laisser le PC allumé. Un client ftp graphique sous DSM va interrompre ses transferts dès que le PC sur lequel tourne le navigateur utilisé pour y accéder sera arrêté. La solution Filezilla ce que j'ai implicitement proposé en écrivant "On dispose forcément a coté d'une machine sachant faire client ftp" (je pensais justement à Filezilla sur PC). Et encore ne faut-il pas que ce soit une appli web pour les raisons que j'ai expliquées

Alors un client en mode graphique n'est *définitivement* pas la solution: des que le navigateur web qui aura été utilisé pour y accéder va se terminer, le client ftp va lui aussi se terminer, ce qui revient à laisser le PC allumé http://www.gnu.org/software/wget/manual/wget.html Sur le syno, la commande est "/usr/syno/bin/wget" Pour avoir le détail des options supportées par cette version, taper: /usr/syno/bin/wget --help

Je n'ai pas le même ressenti: me semble au contraire que le besoin soit assez confidentiel. (comme quoi ...) Apres tout, on peut bien imaginer que personne n'a un Syno tout seul sur son réseau. On dispose forcément a coté d'une machine sachant faire client ftp. Et puis, sous DSM, reste toujours la solution "wget" en ligne de commande (qui peut donc être scripté et lancé en tache de fond, un avantage par rapport à un client graphique), installé de base.

Dans tous les cas une application web (en php) ne pourra écrire sur le NAS que dans des répertoires autorisés en lecture/écriture au compte ou au groupe "http" (sous lequel tourne le serveur apache "user") à moins de savoir utiliser le module "suPHP" (qui est intégré de base dans DSM: CF "/etc/httpd/modules/mod_suphp.so") mais je n'ai pas d'expérience de ce machin.

Autant expliquer la manip alors Pour cela, suffit que le fichier "index.html" du dossier "web" contienne: <meta http-equiv="refresh" content="0; URL=/photo">

Essaie de regarder le contenu des deux fichiers "/var/log/upstart/sshd.log" et "/var/log/upstart/ssh-shell.log" tu y trouvera peut-être des indications sur la cause de l'erreur (je pencherai pour une erreur de syntaxe dans sshd-config).

Je viens de découvrir ça aussi, zut **EDIT** Et une solution de contournement est ici: