Perte du Syno après désactivation de SMB

netgus · le 15 octobre 2016

Bonjour à tous,

Comme suite à un problème de performance avec SMB sous Mac, j'ai décidé de désactiver SMB, de faire un reset du cache SMB et de le redémarrer. Seulement, voilà, après le redémarrage, plus d'accès à l'interface web, plus d'accès afp://, mais je suis capable d'y accéder en ssh (sftp). J'ai accès à l'ensemble de mes dossiers si cher à mes yeux. C'est ce pourquoi, je me permets d'ouvrir un billet pour avoir un regard (très) avisé.

Avant d'aller plus loin, si quelqu'un a une idée du problème et surtout de comment le solutionné, je suis preneur. En attendant, je sauvegarde certaines choses via sftp.

Ma question serait: est-il possible de réinstaller le système par dessus l'ancien sans bien entendu détruire les dossiers ?

Pour votre information:

Syno DS1511+

DSM 6.0.2-8451 Update 2

Merci pour votre aide.

Modifié le 15 octobre 2016 par netgus

Fenrir · le 15 octobre 2016

La réinstallation (double reset) ne supprime pas les fichiers, mais si tu as encore accès au nas en ssh, commence par le rebooter proprement (reboot).

netgus · le 16 octobre 2016

Merci pour votre réponse et votre aide.

J'ai fait un reboot sous ssh, mais après celui-ci, je suis toujours en mesure d'y accéder en ssh, mais j'ai perdu l'accès en sftp. Erreur:impossible de récupérer le contenu du dossier. Timeout. J,ai l'impression qu'à chaque reboot, j'en perds un petit peu.

Pour être sur de suivre la procédure du double reset. C'est bien cette procédure: https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/General/How_to_reset_your_Synology_NAS

Réinitialiser pour réinstaller le système d'exploitation?

Merci

Fenrir · le 16 octobre 2016

Tes disques sont peut être entrain de lâcher.

Commence par sauvegarder tes données (tu peux activer un service avec synoservice, par exemple : synoservice --enable ftpd ; synoservice --restart ftpd).

Ensuite contrôle les disques (tu as plein d'exemples sur le forum).

Pour la réinstallation, c'est le point 3 de ton lien.

netgus · le 16 octobre 2016

Là, je vais attendre mes limites. La hardware n'est vraiment pas mon fort.

Le service ftpd était déjà actif sur mon syno et il était encore opérationnel hier (copie de fichier). Maintenant, le service est à l'écoute, mais je m'arrête au chargement "/" de la structure.

Pour le contrôle des disques, je suis en train de lancer les commandes suivantes:

sudo syno_poweroff_task -d

vgchange -ay

e2fsck -nvf -C 0 /dev/vg1/lv --> j'en suis-là
e2fsck 1.42.6 (21-Sep-2012)
Warning! /dev/vg1/lv is in use.
Warning: skipping journal recovery because doing a read-only filesystem check.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
/lost+found not found. Create? no

Pass 4: Checking reference counts
Pass 5: Checking group summary information

Je ne suis pas un expert sur le sujet, mais si ce test est sans erreur, cela veut dire que ma structure de fichier et mon système est bon ?

Peut-on lancer un test S.M.A.R.T depuis la console ?

Encore merci pour votre aide.

Voilà le résultat final:

e2fsck -nvf -C 0 /dev/vg1/lv
e2fsck 1.42.6 (21-Sep-2012)
Warning! /dev/vg1/lv is in use.
Warning: skipping journal recovery because doing a read-only filesystem check.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
/lost+found not found. Create? no

Pass 4: Checking reference counts
Pass 5: Checking group summary information

Free blocks count wrong (241067901, counted=241067880).
Fix? no

Free inodes count wrong (425090536, counted=425090524).
Fix? no

1.41.10-1358: ********** WARNING: Filesystem still has errors **********

1057304 inodes used (0.25%, out of 426147840)
19318 non-contiguous files (1.8%)
375 non-contiguous directories (0.0%)
# of inodes with ind/dind/tind blocks: 0/0/0
Extent depth histogram: 1052679/2638/19/0/1
1463513219 blocks used (85.86%, out of 1704581120)
0 bad blocks
513 large files

750622 regular files
288579 directories
4 character device files
0 block device files
2 fifos
515 links
18078 symbolic links (1942 fast symbolic links)
22 sockets
------------
1057822 files

Quelle commande dois-je utiliser pour fixer ce problème?

e2fsck -pvf -C 0 /dev/vg1/lv
e2fsck -yvf -C 0 /dev/vg1/lv

merci pour votre aide.

Fenrir · le 16 octobre 2016

sudo -s
df -h
cat /proc/mdstat
smartctl --health /dev/sda

netgus · le 16 octobre 2016

pour mes 5 disques, j'ai:

SMART Health Status: OK

Fenrir · le 16 octobre 2016

et le reste des commandes ?

netgus · le 16 octobre 2016

sh-4.3# df -h

Filesystem Size Used Avail Use% Mounted on

/dev/md0 2.3G 875M 1.4G 40% /

none 1.5G 4.0K 1.5G 1% /dev

/tmp 1.5G 668K 1.5G 1% /tmp

/run 1.5G 2.3M 1.5G 1% /run

/dev/shm 1.5G 4.0K 1.5G 1% /dev/shm

none 4.0K 0 4.0K 0% /sys/fs/cgroup

/dev/mapper/vol1-origin 6.3T 5.4T 919G 86% /volume1

sh-4.3# cat /proc/mdstat

Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]

md2 : active raid5 sdb5[6] sdc5[2] sdd5[3] sde5[7] sda5[5]

1231349248 blocks super 1.1 level 5, 64k chunk, algorithm 2 [5/5] [UUUUU]

md3 : active raid1 sda7[0] sdb7[1]

2930247808 blocks super 1.1 [2/2] [UU]

md4 : active raid5 sdb6[6] sdc6[2] sdd6[3] sde6[7] sda6[5]

2656732672 blocks super 1.1 level 5, 64k chunk, algorithm 2 [5/5] [UUUUU]

md1 : active raid1 sda2[0] sdb2[1] sdc2[2] sdd2[4] sde2[3]

2097088 blocks [5/5] [UUUUU]

md0 : active raid1 sda1[0] sdb1[1] sdc1[2] sdd1[3] sde1[4]

2490176 blocks [5/5] [UUUUU]

unused devices: <none>

sh-4.3# smartctl --health /dev/sd

sda sda2 sda6 sdb sdb2 sdb6 sdc sdc2 sdc5 sdd sdd2 sdd5 sde sde2 sde5

sda1 sda5 sda7 sdb1 sdb5 sdb7 sdc1 sdc3 sdc6 sdd1 sdd3 sdd6 sde1 sde3 sde6

Je viens de perdre mon accès ssh. J'essaye de l'éteindre proprement, mais il a un peu de mal. Je vais lui donner un peu de temps.

Sinon, j'ai essayé de lancer la commande:

e2fsck -yvf -C 0 /dev/vg1/lv

e2fsck 1.42.6 (21-Sep-2012)

/dev/vg1/lv is in use.

e2fsck: Cannot continue, aborting.

Et c'est en lançant la commande que j'ai perdu mon accès ssh et puis, plus rien.

syno_poweroff_task

Connection to x.x.x.x closed by remote host.

Le Syno est de nouveau Up avecun accès ssh.

Si je veux corriger mon problème, il semblerait que je dois lancer cette commande:

sudo fsck.ext4 -yvf -C 0 /dev/vg1/lv

Password:

e2fsck 1.42.6 (21-Sep-2012)

/dev/vg1/lv is in use.

e2fsck: Cannot continue, aborting.

mais comment faire pour que lv ne soit pas en utilisation ?

smartctl --health /dev/sda
smartctl 6.5 (build date Aug 2 2016) [x86_64-linux-3.10.77] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

smartctl --health /dev/sdb
smartctl 6.5 (build date Aug 2 2016) [x86_64-linux-3.10.77] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

smartctl --health /dev/sdc
smartctl 6.5 (build date Aug 2 2016) [x86_64-linux-3.10.77] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK

smartctl --health /dev/sdd
smartctl 6.5 (build date Aug 2 2016) [x86_64-linux-3.10.77] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK

smartctl --health /dev/sde
smartctl 6.5 (build date Aug 2 2016) [x86_64-linux-3.10.77] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK

netgus · le 16 octobre 2016

Faut-il que lance cette commande:

umount -l /volume1

puis, je relance ma commande:

sudo fsck.ext4 -yvf -C 0 /dev/vg1/lv

puis, je remonte mon volume une fois terminé ?

Brunchto · le 16 octobre 2016

Si tu lances synoassistant, tu as quoi comme statut du syno?

netgus · le 16 octobre 2016

Le statut est : Prêt

Fenrir · le 16 octobre 2016

Tu devrais aller voir ce que les logs ont à dire

netgus · le 16 octobre 2016

Quel log serait-il interessant de regarder ?

ls -l /var/log/

total 36504

-rw-rw---- 1 system log 72078 Oct 16 11:35 apparmor.log

-rw-r--r-- 1 root root 3823 Nov 9 2015 ash_history.log

-rw-r----- 1 root log 6472751 Oct 16 13:32 auth.log

-rw-rw---- 1 system log 77035 Oct 16 11:36 bash_err.log

-rw-rw---- 1 system log 13610 Oct 16 13:33 bash_history.log

drwxr-xr-x 2 root root 4096 Feb 28 2013 cluster

drwx------ 5 root root 4096 Apr 11 2011 cores

-rw-r--r-- 1 root root 5105 Jun 16 2015 disk_log.xml

-rw-r--r-- 1 root root 6178 Oct 16 11:35 disk_overview.xml

-rw-r--r-- 1 root root 628035 Oct 16 11:36 dmesg

-rw-r--r-- 1 root root 50204 Jun 28 21:48 dmesg.1.xz

-rw-r--r-- 1 root root 50168 Aug 25 2015 dmesg.2.xz

-rw-r--r-- 1 root root 49232 Dec 17 2014 dmesg.3.xz

-rw-r--r-- 1 root root 47984 Apr 9 2014 dmesg.4.xz

-rw-r--r-- 1 root root 4209854 Mar 7 2013 dms.log

-rw-r--r-- 1 root root 197758 Sep 9 2012 dms.log.1.gz

-rw-r--r-- 1 root root 195225 Dec 19 2012 dms.log.2.gz

-rw-r--r-- 1 root root 225161 Oct 10 17:16 dpkg.log

-rw-r--r-- 1 root root 138805 Oct 10 17:16 dpkg_upgrade.log

-rw-rw---- 1 system log 7246 Oct 16 11:36 esynoscheduler.log

-rw-r----- 1 root root 1568 May 12 2015 gcpd.log

drwxr-xr-x 2 root root 4096 May 17 09:43 httpd

-rw-rw---- 1 system log 3982648 Oct 16 11:35 iscsi.log

-rw-rw---- 1 system log 28156 Oct 16 04:34 iscsi.log.1.xz

-rw-rw---- 1 system log 44604 Oct 15 21:44 iscsi.log.2.xz

-rw-r----- 1 root root 237024 Oct 22 2015 iscsi.log.3.xz

-rw-r----- 1 root root 240252 Oct 22 2015 iscsi.log.4.xz

-rw-rw---- 1 system log 5190543 Oct 16 11:36 kern.log

drwxr-xr-x 2 admin users 4096 Mar 10 2014 lighttpd

-rw-r--r-- 1 root root 56859 May 12 2015 log.nmbd

-rw-r--r-- 1 root root 1530262 Apr 21 2015 log.smbd

-rw-r--r-- 1 root root 1540 Oct 22 2014 log.wb-BUILTIN

-rw-r--r-- 1 root root 1540 Oct 22 2014 log.wb-DISKSTATION

-rw-r--r-- 1 root root 5856 Oct 22 2014 log.wb-NETGUS

-rw-r--r-- 1 root root 5500 Oct 22 2014 log.winbindd

-rw-r--r-- 1 root root 0 Apr 11 2011 log.winbindd-dc-connect

-rw-r--r-- 1 root root 1975 Oct 22 2014 log.winbindd-idmap

-rw-rw-rw- 1 root root 82 Nov 30 2014 lv_log_expand

-rw-rw---- 1 system log 5988262 Oct 16 13:00 messages

-rw-r--r-- 1 root root 16790 Jul 20 2013 messages.0.gz

-rw-r--r-- 1 root root 16376 May 13 2013 messages.1.gz

-rw-r----- 1 root root 165820 Apr 24 2015 messages.1.xz

-rw-r--r-- 1 root root 13891 Apr 12 2013 messages.2.gz

-rw-r----- 1 root root 300440 Jan 19 2015 messages.2.xz

-rw-r--r-- 1 root root 19836 Mar 5 2013 messages.3.gz

-rw-r----- 1 root root 291608 Oct 19 2013 messages.3.xz

-rw-rw-rw- 1 root root 0 Mar 7 2013 mount.log

drwxr-x--- 2 http root 4096 Mar 10 2014 nginx

-rw-r--r-- 1 root root 54 Oct 2 2012 ntp.log

-rw-rw-rw- 1 root root 530119 Oct 16 11:35 opentftp.log

-rw-r--r-- 1 root root 46 Sep 3 2015 ovh_dyndns_restore_conf.log

-rw-rw-rw- 1 root root 0 Nov 28 2014 partition

-rw------- 1 root root 319891 Oct 16 11:35 php-fpm.log

-rw-rw---- 1 system log 276701 Oct 16 11:35 postgresql.log

-rw-rw---- 1 system log 3650 Oct 14 02:45 router.log

drwxr-xr-x 2 root root 4096 May 12 2015 samba

-rw-rw---- 1 system log 161459 Oct 16 11:37 scemd.log

drwxr-x--- 2 root root 4096 Oct 10 17:17 selfcheck

-rw-r--r-- 1 root root 102 Jun 16 2015 smart_quick_log

-rw-rw-rw- 1 root root 14181 Oct 16 11:35 space_operation_error.log

drwxr-xr-x 2 SurveillanceStation SurveillanceStation 4096 Mar 30 2016 surveillance

-rw-r--r-- 1 root root 4203 Oct 16 11:36 synocmsclient.log

-rw-r--r-- 1 root root 70575 Oct 16 09:57 synocrond-execute.log

-rw-rw---- 1 system log 14326 Oct 16 11:35 synocrond.log

-rw-r----- 1 root root 127099 Mar 25 2016 synodtv.log

-rw-rw---- 1 system log 23850 Oct 16 03:31 synofeasibilitycheck.log

-rw-rw---- 1 system log 35110 Oct 10 17:58 synoindex.log

-rw-r--r-- 1 root root 9523 Sep 5 16:10 synoinfo.conf.bad

drwxr-x--- 2 root root 4096 Oct 16 13:32 synolog

-rw-r--r-- 1 root root 2032431 Oct 15 14:59 synopkg.log

-rw-r--r-- 1 root root 94776 Mar 25 2016 synopkg.log.1.xz

-rw-rw---- 1 system log 4809 Oct 16 03:31 synopoweroff.log

-rw-rw---- 1 system log 1651201 Oct 16 11:36 synoservice.log

-rw------- 1 root root 61 Aug 27 2013 synosys.log

-rw-r--r-- 1 root root 6477 Oct 10 17:16 synoupdate.log

-rw-rw---- 1 system log 1025615 Oct 16 11:35 syslog.log

-rw-r----- 1 root root 31952 Nov 2 2015 syslog.log.1.xz

-rw-r----- 1 root root 30004 Aug 9 2015 syslog.log.2.xz

-rw-r----- 1 root root 25872 Jul 15 2015 syslog.log.3.xz

-rw-r----- 1 root root 18868 May 30 2015 syslog.log.4.xz

-rw-rw-rw- 1 root root 163 Mar 7 2013 timebkp.debug

drwxr-xr-x 2 root root 4096 Oct 15 15:10 upstart

Fenrir · le 16 octobre 2016

ls -lart

et regardes les plus récents (qui datent de ton problème)

idem dans le dossier synolog

netgus · le 16 octobre 2016

Voilà les logs des deux derniers jours, puisque le problème est arrivé hier:

-rw-r--r-- 1 root root 2032431 Oct 15 14:59 synopkg.log

drwxr-xr-x 2 root root 4096 Oct 15 15:10 upstart

-rw-rw---- 1 system log 44604 Oct 15 21:44 iscsi.log.2.xz

-rw-rw---- 1 system log 4809 Oct 16 03:31 synopoweroff.log

-rw-rw---- 1 system log 23850 Oct 16 03:31 synofeasibilitycheck.log

-rw-rw---- 1 system log 28156 Oct 16 04:34 iscsi.log.1.xz

-rw-r--r-- 1 root root 70575 Oct 16 09:57 synocrond-execute.log

drwxr-xr-x 18 root root 4096 Oct 16 11:35 ..

-rw-rw-rw- 1 root root 14181 Oct 16 11:35 space_operation_error.log

-rw-rw---- 1 system log 14326 Oct 16 11:35 synocrond.log

-rw-r--r-- 1 root root 6178 Oct 16 11:35 disk_overview.xml

-rw-rw---- 1 system log 3982648 Oct 16 11:35 iscsi.log

-rw-rw-rw- 1 root root 530119 Oct 16 11:35 opentftp.log

-rw-rw---- 1 system log 276701 Oct 16 11:35 postgresql.log

-rw-rw---- 1 system log 72078 Oct 16 11:35 apparmor.log

-rw------- 1 root root 319891 Oct 16 11:35 php-fpm.log

-rw-rw---- 1 system log 1025615 Oct 16 11:35 syslog.log

-rw-rw---- 1 system log 77035 Oct 16 11:36 bash_err.log

-rw-r--r-- 1 root root 4203 Oct 16 11:36 synocmsclient.log

-rw-r--r-- 1 root root 628035 Oct 16 11:36 dmesg

-rw-rw---- 1 system log 7246 Oct 16 11:36 esynoscheduler.log

-rw-rw---- 1 system log 1651201 Oct 16 11:36 synoservice.log

-rw-rw---- 1 system log 161459 Oct 16 11:37 scemd.log

-rw-rw---- 1 system log 5190701 Oct 16 13:58 kern.log

-rw-rw---- 1 system log 5988525 Oct 16 14:00 messages

drwxr-xr-x 12 root root 4096 Oct 16 14:01 .

-rw-rw---- 1 system log 5988264 Oct 16 14:01 messages.save.1

-rw------- 1 root root 7967 Oct 16 14:01 messages.save

-rw-r----- 1 root log 6475707 Oct 16 14:02 auth.log

drwxr-x--- 2 root root 4096 Oct 16 14:02 synolog

-rw-rw---- 1 system log 14781 Oct 16 14:02 bash_history.log

J'ai essayé d'ouvrir le log "message", mais je ne suis pas en mesure de l'ouvrir (cat, nano, VI) = écran noir sauf VI "/var/log/messages" 53830L, 5988525C

Pour information, j'ai installé Video Station et ça fonctionne depuis ma télé. Donc certains services fonctionnent encore.

le synopkg ça doit être la mise à jour que j'ai faite (audio station, il me semble)

sudo ls -lart /var/log/synolog/

Password:

total 8972

-rw-rw-rw- 1 root root 6853 Aug 27 2013 synosur.log

-rw-r----- 1 root root 29112 Oct 20 2014 synoindex.log.1.xz

-rw-r----- 1 root root 1053810 Nov 2 2014 synoindex.log.0

-rw-r----- 1 root root 1833 Nov 3 2014 synonetbkp.log

-rw-r----- 1 root root 3019 Jan 15 2015 synobackup.log

-rw-r----- 1 root root 53444 Apr 9 2015 synoconn.log.3.xz

-rw-r----- 1 root root 60668 Jul 5 2015 synoconn.log.2.xz

-rw-r----- 1 root root 65764 Aug 31 2015 synoconn.log.1.xz

-rw-r--r-- 1 root root 2326528 Mar 25 2016 .SYNOSYSLOGDB

-rw-rw---- 1 system log 1048643 May 28 11:59 synoconn.log.0

-rw-rw---- 1 system log 618076 Jun 7 20:20 synoindex.log

-rw-rw---- 1 system log 757254 Oct 16 11:36 synosys.log

drwxr-xr-x 12 root root 4096 Oct 16 14:15 ..

-rw-rw---- 1 system log 898892 Oct 16 14:16 synoconn.log

-rw-r--r-- 1 root root 2196480 Oct 16 14:16 .SYNOACCOUNTDB

drwxr-x--- 2 root root 4096 Oct 16 14:16 .

Modifié le 16 octobre 2016 par netgus

Fenrir · le 16 octobre 2016

utilise cat pour afficher les fichiers

netgus · le 16 octobre 2016

Merci pour ta perceverance, mais j'ai le même résultat avec cat.

Dès que je lance la commande, la console se fige. Je me suis baladé dans l'arborescence pour voir si j'étais en mesure d'ouvrir des fichiers, mais le problème est identique...

J'ai bien peur qu'on est fait le tour du sujet.

Est-ce qu'un double reset va régler mon problème d'après vous ?

Est-ce que l'erreur suivante peut-être mon problème : 1.41.10-1358: ********** WARNING: Filesystem still has errors **********

Ce qui est bizarre, c'est qu'un simple désactivation d'un service SMB + suppression du cache puisse rendre un tel résultat.

En attendant, merci pour vos efforts.

netgus · le 17 octobre 2016

Bon, j'ai pris la décision de faire un reset du Syno.

Tout semble maintenant fonctionnel. Je ferai des tests plus approfondis cette semaine.

Merci à ceux qui m'ont aidé.

Fenrir · le 17 octobre 2016

Il y a 10 heures, netgus a dit :

Est-ce que l'erreur suivante peut-être mon problème : 1.41.10-1358: ********** WARNING: Filesystem still has errors **********

Il y a 10 heures, netgus a dit :

Ce qui est bizarre, c'est qu'un simple désactivation d'un service SMB + suppression du cache puisse rendre un tel résultat.

À mon avis ça a simplement mis en évidence l'erreur sur les disques, si tu as de la chance c'était simplement une corruption, mais si c'est un soucis physique sur les disques (bloc endommagé), tes problèmes risquent de réapparaître (pas nécessairement sous la même forme).

=>backup à jour et automatiques

netgus · le 18 octobre 2016

Bonjour à tous,

Je vais lancer un test sur chaque disque cette nuit.

J'ai comparé les valeurs de mes disques:

2 X ST4000NM0033-9ZM170 3,6 To (récent)

les valeurs Raw_Read_Error_Rate et Seek_Error_Rate sont à plus 100000000 plus l'un 2000000000 pour l'autre

3 X WD1002FAEX-00Y9A0 931 Go (plus vieux)

les valeurs Raw_Read_Error_Rate (4000) et Seek_Error_Rate 0

**************************************************************************************************

Mais j'ai un autre problème que me préoccupe un peu. Initialement, j'avais ouvert à l'extérieur un accès sftp à plusieurs personnes.

Je pensais quand réinstallant le système, les droits pour ces utilisateurs allaient devoir être recréés.. EH BIEN NON.

ILS ONT TOUS LEUR ACCÈS ET MÊME PIRE. ILS ONT ACCÈS À CERTAINS DOSSIERS PERSONNEL POUR LEQUEL JE N'AVAIS PAS DONNÉ D'ACCÈS.

Je suppose qu'il doit rester des fichiers de conf dans le dossier volume1 qui doit permet l'accès.

Quelqu'un aurait-il une idée du problème svp.

Modifié le 18 octobre 2016 par netgus

Fenrir · le 18 octobre 2016

Si tu as fait une réinstallation, tous les droits de bas niveau (droits ntfs ou placés via filestation) sont à refaire, même ceux qui ont encore l'air ok. Les seuls droits qui sont fiables sont ceux aux niveau des partages, c'est pour ça qu'on déconseille de jouer avec les droits dans les sous dossiers.

A noter aussi que le sftp (port 22) n'est pas à mettre entre toutes les mains, il vaut mieux ouvrir le FTPS (port 21), même si parfois c'est un peu plus galère avec le nat.

netgus · le 18 octobre 2016

Fenrir, merci de t'intéresser à tous mes problèmes. Je t'en remercie.

Grâce à tes explications, j'ai trouvé le groupe everyone dans les dossiers concernés. Je l'ai supprimé, ce qui fait que les personnes n'ont plus accès aux dossiers, cependant, et malgré que j'ai supprimé les dossiers dans "homes", que les comptes n'existent pas dans le syno, ils sont quand même en mesure ouvrir une session sftp. Je ne suis pas passé compétent pour aller plus loin. Et j'avoue être surpris, car pour moi pas de compte pas d'accès au(x )service(s). L'accès anonyme n'est pas autorisé.

Il doit y avoir un fichier de conf que le permet...

le FTP(s) est au programme, mais le temps me manque et la simplicité est tellement plus facile... Mais là je ne vais pas avoir le choix, surtout si je ne suis pas en mesure de contrôler l'accès sftp.

Fenrir · le 18 octobre 2016

il y a 39 minutes, netgus a dit :

les comptes n'existent pas dans le syno, ils sont quand même en mesure ouvrir une session sftp

??? s'ils peuvent se connecter c'est qu'ils ont un compte =>

si tu as vraiment réinstallé le nas (ça te demande de re télécharger DSM) : leurs comptes ont forcement été supprimés
- vérifie que c'est bien du sftp (port 22) et qu'ils n'utilisent pas le compte admin
sinon c'est que tu as fait un simple reset (reset mdp admin+conf réseau) : dans ce cas tout est resté
- si les comptes ne sont plus visibles, tu as un bug (qui peut être lié à ton soucis de disque)

Pour voir les comptes qui existent vraiment sur un linux : cat /etc/passwd

Mais à mon avis tu devrais mettre ce problème de droits de coté, ton vrai problème est celui de tes disques qui sont en erreur, c'est à corriger avant de faire autre chose.

fais tes backups
identifie le ou les disques en erreurs (il faut les sortir 1 par 1 du nas et les tester depuis un pc avec le soft du constructeur)
- si un seul disque est en erreur, tu n'as qu'à le remplacer
- si 2 disques ou plus présentent des erreurs => ton raid est mort (ou presque) => il faut repartir de zéro :
  1. formater les disques encore sains
  2. compléter avec des disques neufs et testés
  3. tout remettre dans le nas
  4. faire une installation comme au jour du déballage
  5. refaire les paramétrages
  6. réinstaller les applis
  7. recréer les comptes
  8. remettre les fichiers

netgus · le 18 octobre 2016

J'ai bien fait un reset complet du syno.. bouton reset jusqu'au premier bcp, on relâche, puis on réappuie dessus jusqu'au prochain bip.

J'ai lancé l'utilitaire qui m'a dit un message comme quoi il fallait le réinstaller la partition système.

Une page web s'est ouvert avec un wizard que j'ai suivi jusqu'au bout.

J'ai recréé mon compte admin (à moi) et à se stade, il avait et il y encore que trois compte (admin, le mien et Guest)

Guest et admin sont désactivés.

Par contre, mon volume1 est resté comme il était avant mon problème.

C'est un ami qui m'a dit qu'il avait accès à d'autres dossiers qui m'a fait réagir.

À la suite de ça, j'ai supprimé tous les dossiers dans homes, mais ça n'a rien changé, ils avaient encore accès aux dossiers. C'est en supprimant everyone qu'ils ont perdu la vue sur les dossiers, mais ils sont toujours capables d'accéder au service.

Je sais que c'est difficile à croire, mais c'est le cas. Il accéder à mon syno avec une clé et/ou un compte en cache quelque part.

J'ai vérifier passwd et il n'y a rien que mon compte...

Pour les disques, je vais les tester ce soir.

Modifié le 19 octobre 2016 par netgus

Connexion

Perte du Syno après désactivation de SMB

Messages recommandés

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Rejoindre la conversation

Qui est en ligne 4 membres, 0 anonyme, 648 invités (Afficher la liste complète)

Contributeurs populaires

Information importante