Hallo Allerseits,
Auf meiner DS918+ (mit DSM 6.2.2-24922 Update 3) habe ich zwei Probleme festgestellt, die möglicherweise zusammenhängen:
- Verschlüsselte Freigegebene Ordner lassen sich (teilweise) nicht mehr einhängen
- Die DSM-Aktualisierung kann wegen fehlender Systemkapazität nicht durchgeführt werden
Zu 1:
Meine verschlüsselten Ordner (sechs an der Zahl) hänge ich immer manuell nach einem Neustart wieder ein. Keiner der verschlüsselten Ordner ist ein Home-Verzeichnis.
Nach einem kürzlichen DSM-Update (aber erst beim zweiten Booten, einige Tage nach dem Update) habe ich festgestellt, dass beim Anhängen des vierten oder fünften Ordners die Fehlermeldung
Vorgang fehlgeschlagen. Bitte melden Sie sich erneut im DSM an und versuchen Sie es erneut erscheint. Der betreffende Ordner wurde jedoch erfolgreich angehängt, auch wenn man die Ordner-Übersicht neu laden muss. Nach einer erneuten Anmeldung in der Weboberfläche lassen sich die restlichen Ordner jedoch nicht anhängen, es erscheint die Fehlermeldung
Dieser gemeinsame Ordner ist durch einen anderen Vorgang gesperrt. Bitte versuchen Sie es später erneut. Das NAS zu rebooten hilft nicht, der Fehler tritt (scheinbar zufällig) beim Anhängen eines der ersten 4-5 Ordner auf.
Hier im Forum habe ich die Möglichkeit gefunden, die Ordner in der Kommandozeile mit
Code:
sudo synoshare --enc_mount ORDNERNAME ORDNERPASSWORT
einzuhängen. Der Befehl hängt sich im Terminal nach jeder Eingabe auf und muss mit [Strg+C] beendet werden - der Ordner wurde jedoch erfolgreich gemountet.
Mein Workaround ist nun also, nach jedem NAS-Reboot jeden Ordner per CLI einzeln zu mounten und den Befehl jeweils mit [Strg+C] zu beenden.
Es wäre natürlich toll, wenn ich die Ordner wieder per Weboberfläche aus der Ferne (ohne SSH-verbindung) mounten könnte.
(Möglicherweise hiermit zusammenhängend: beim Arbeiten mit Emby sind mir neue Ordner als Unterordner von /volume1 & /volume2 aufgefallen, mit dem Namensschema @NAME@ - diese Ordner gibt es aber nur für die verschlüsselten Ordner, unverschlüsselte Ordner liegen nur als NAME vor. Möglicherweise habe ich diese Ordner vorher aber auch nur übersehen und sie haben nicht mit dem Problem zu tun.)
Zu 2:
Beim Suchen nach einer neuen DSM-Version (in der Hoffnung, Problem #1 zu lösen) bin ich auf die Fehlermeldung
Systemkapazität reicht für Aktualisierung nicht aus. Bitte wenden Sie sich für Unterstützung an den Synology Support gestoßen. Nach Forum-Tipps habe ich mal das Rootverzeichnis untersucht:
Code:
ash-4.3# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/md0 2.3G 2.1G 126M 95% /
none 3.9G 0 3.9G 0% /dev
/tmp 3.9G 2.1M 3.9G 1% /tmp
/run 3.9G 4.3M 3.9G 1% /run
/dev/shm 3.9G 12K 3.9G 1% /dev/shm
none 4.0K 0 4.0K 0% /sys/fs/cgroup
cgmfs 100K 0 100K 0% /run/cgmanager/fs
/dev/md4 7.0T 6.7T 349G 96% /volume2
/dev/mapper/cachedev_0 14T 14T 587G 96% /volume1
tmpfs 1.0T 0 1.0T 0% /dev/virtualization
/volume1/@medien@ 14T 14T 587G 96% /volume1/medien
/volume2/@medien2@ 7.0T 6.7T 349G 96% /volume2/medien2
/volume1/@privat@ 14T 14T 587G 96% /volume1/privat
/volume1/@temp@ 14T 14T 587G 96% /volume1/temp
/volume1/@powernas@ 14T 14T 587G 96% /volume1/powernas
/volume2/@privat2@ 7.0T 6.7T 349G 96% /volume2/privat2
Code:
ash-4.3# du -xhd 1 /
4.0K /lost+found
8.3M /etc.defaults
4.0K /tmpRoot
9.5M /etc
22M /.syno
6.9M /var.defaults
20K /root
8.0K /boot
20K /.system_info
4.0K /initrd
4.0K /mnt
208M /var
16K /opt
16K /volumeUSB2
32K /.old_patch_info
940M /usr
886M /volumeUSB1
2.1G /
Code:
ash-4.3# ls -alsS /
total 80
0 drwxr-xr-x 14 root root 19120 Sep 13 17:02 dev
4 drwxr-xr-x 27 root root 4096 Sep 13 16:01 .
4 drwxr-xr-x 27 root root 4096 Sep 13 16:01 ..
4 drwxr-xr-x 3 root root 4096 Jul 9 02:43 boot
4 drwxr-xr-x 50 root root 4096 Sep 13 16:04 etc
4 drwxr-xr-x 43 root root 4096 Aug 27 03:46 etc.defaults
4 drwxr-xr-x 2 root root 4096 May 9 23:51 initrd
4 drwx------ 2 root root 4096 May 9 23:51 lost+found
4 drwxr-xr-x 2 root root 4096 May 9 23:51 mnt
4 drwxr-xr-x 3 root root 4096 May 18 03:48 .old_patch_info
4 drwx--x--x 3 root root 4096 Aug 27 22:51 opt
4 drwx------ 3 root root 4096 Jul 9 02:43 root
4 drwxr-xr-x 4 root root 4096 Aug 27 03:46 .syno
4 drwxr-xr-x 2 root root 4096 May 18 11:33 .system_info
4 drwxr-xr-x 2 root root 4096 Jul 9 02:43 tmpRoot
4 drwxr-xr-x 11 root root 4096 May 9 23:04 usr
4 drwxr-xr-x 18 root root 4096 Sep 13 16:01 var
4 drwxr-xr-x 14 root root 4096 May 18 03:49 var.defaults
4 drwxr-xr-x 4 root root 4096 Aug 30 03:31 volumeUSB1
4 drwxr-xr-x 3 root root 4096 Jul 10 21:34 volumeUSB2
0 drwxrwxrwt 24 root root 2500 Sep 13 17:49 tmp
0 drwxr-xr-x 34 root root 2400 Sep 13 17:30 run
4 -rw------- 1 root root 1024 Jun 9 2018 .rnd
0 drwxr-xr-x 1 root root 832 Sep 13 16:04 volume1
0 drwxr-xr-x 1 root root 84 Sep 13 16:04 volume2
0 lrwxrwxrwx 1 root root 9 May 18 03:48 lib32 -> usr/lib32
0 lrwxrwxrwx 1 root root 8 May 18 03:48 sbin -> usr/sbin
0 lrwxrwxrwx 1 root root 7 May 18 03:48 bin -> usr/bin
0 lrwxrwxrwx 1 root root 7 May 18 03:48 lib -> usr/lib
0 lrwxrwxrwx 1 root root 7 May 18 03:48 lib64 -> usr/lib
0 drwxr-xr-x 7 root root 0 Sep 13 16:02 config
0 dr-xr-xr-x 554 root root 0 Sep 13 16:02 proc
0 dr-xr-xr-x 12 root root 0 Sep 13 16:01 sys
Code:
ash-4.3# ls -alsS /dev/
total 4
0 drwxr-xr-x 14 root root 19120 Sep 13 17:02 .
4 drwxr-xr-x 27 root root 4096 Sep 13 16:01 ..
0 drwxr-xr-x 2 root root 1320 Sep 13 16:03 char
0 drwxr-xr-x 2 root root 1160 Sep 13 16:02 block
0 drwxr-xr-x 2 root root 140 Sep 13 16:02 bsg
0 drwxr-xr-x 6 root root 120 Sep 13 16:02 cpu
0 drwxrwxrwx 2 root root 100 Sep 13 16:02 dri
0 drwxr-xr-x 2 root root 100 Sep 13 16:02 mapper
0 drwxrwxrwt 2 root root 100 Sep 13 16:03 shm
0 drwxr-xr-x 3 root root 60 Sep 13 16:01 bus
0 drwxr-xr-x 2 root root 60 Sep 13 16:02 net
0 drwxr-xr-x 2 root root 60 Sep 13 16:02 vg1000
0 drwx--x--x 3 root root 60 Sep 13 16:03 virtualization
0 lrwxrwxrwx 1 root root 15 Sep 13 16:02 stderr -> /proc/self/fd/2
0 lrwxrwxrwx 1 root root 15 Sep 13 16:02 stdin -> /proc/self/fd/0
0 lrwxrwxrwx 1 root root 15 Sep 13 16:02 stdout -> /proc/self/fd/1
0 lrwxrwxrwx 1 root root 13 Sep 13 16:02 fd -> /proc/self/fd
0 lrwxrwxrwx 1 root root 11 Sep 13 16:02 core -> /proc/kcore
0 crw------- 1 root root 10, 234 Sep 13 16:02 btrfs-control
0 crw------- 1 root root 5, 1 Sep 13 16:02 console
0 crw------- 1 root root 10, 62 Sep 13 16:02 cpu_dma_latency
0 brw------- 1 root root 252, 0 Sep 13 16:02 dm-0
0 brw------- 1 root root 252, 1 Sep 13 16:02 dm-1
0 crw------- 1 root root 29, 0 Sep 13 16:02 fb0
0 crw-rw-rw- 1 root root 1, 7 Sep 13 16:02 full
0 crw-rw-rw- 1 root users 10, 229 Sep 13 16:02 fuse
0 brw-r--r-- 1 root root 8, 0 Sep 13 16:01 hda
0 brw-r--r-- 1 root root 8, 1 Sep 13 16:01 hda1
0 brw-r--r-- 1 root root 8, 2 Sep 13 16:01 hda2
0 brw-r--r-- 1 root root 8, 3 Sep 13 16:01 hda3
0 brw-r--r-- 1 root root 8, 4 Sep 13 16:01 hda4
0 crw------- 1 root root 89, 0 Sep 13 16:02 i2c-0
0 crw------- 1 root root 89, 1 Sep 13 16:02 i2c-1
0 crw------- 1 root root 89, 2 Sep 13 16:02 i2c-2
0 crw------- 1 root root 89, 3 Sep 13 16:02 i2c-3
0 crw------- 1 root root 89, 4 Sep 13 16:02 i2c-4
0 crw------- 1 root root 89, 5 Sep 13 16:02 i2c-5
0 crw------- 1 root root 89, 6 Sep 13 16:02 i2c-6
0 crw------- 1 root root 1, 2 Sep 13 16:02 kmem
0 crw-r--r-- 1 root root 1, 11 Sep 13 16:02 kmsg
0 crw------- 1 root root 10, 232 Sep 13 16:03 kvm
0 srw-rw-rw- 1 system log 0 Sep 13 17:02 log
0 brw------- 1 root root 7, 0 Sep 13 16:02 loop0
0 brw------- 1 root root 7, 1 Sep 13 16:02 loop1
0 brw-r--r-- 1 root root 7, 10 Sep 13 16:02 loop10
0 brw-r--r-- 1 root root 7, 100 Sep 13 16:02 loop100
...
Ich verwende auch den jDownloader2 (via Paketquelle
https://spk.netzbaer.de/), mir ist aber kein Order im Rootverzeichnis aufgefallen, in den jD2 geschrieben haben könnte.
Schonmal Danke im Vorraus für eure Zeit :D