DSM 6.x und darunter Ordner-Entschlüsselung & DSM-Update nicht möglich

Alle DSM Version von DSM 6.x und älter
Status
Für weitere Antworten geschlossen.
Mitglied seit
07. Jul 2018
Beiträge
5
Punkte für Reaktionen
0
Punkte
0
Hallo Allerseits,

Auf meiner DS918+ (mit DSM 6.2.2-24922 Update 3) habe ich zwei Probleme festgestellt, die möglicherweise zusammenhängen:

  1. Verschlüsselte Freigegebene Ordner lassen sich (teilweise) nicht mehr einhängen
  2. 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
Rich (BBCode):
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:

Rich (BBCode):
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

Rich (BBCode):
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    /

Rich (BBCode):
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

Rich (BBCode):
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
 
Mitglied seit
07. Jul 2018
Beiträge
5
Punkte für Reaktionen
0
Punkte
0
Ich habe die Ursache für Problem #2 gefunden: Der Befehl
Rich (BBCode):
du -h --max-depth=1 --exclude=/proc --exclude=/volume? / | sort -h -r
zeigt, dass /VolumeUSB1/ 886MB groß ist. jD2 hat dort Daten abgelegt, obwohl keine Festplatte angeschlossen war. Nach dem Löschen aller Unterordner von /volumeUSB1/usbshare/ meldet "df -h /" 1013MB freien Platz. Die Update-Meldung in der Weboberfläche meldet nun, dass die DSM-Version aktuell ist.

Vermutlich hatte Problem #2 nichts mit #1 zu tun, der betreffende Ordner wurde erst vor kurzem erstellt und #1 war schon vorher aufgetreten.

Falls jemand einen Lösungsvorschlag für Problem #1 hat, wäre ich überglücklich ;)
 

synfor

Benutzer
Sehr erfahren
Mitglied seit
22. Dez 2017
Beiträge
8.583
Punkte für Reaktionen
1.433
Punkte
288
Es war /volumeUSB1/ und nicht obwohl, sondern weil.
 

Matis

Benutzer
Mitglied seit
28. Mai 2015
Beiträge
735
Punkte für Reaktionen
9
Punkte
44
Das Problem #1 habe ich auch.

Beim Einhängen eines von zwei verschlüsselten Ordnern kommt 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 läßt sich der andere Ordner nicht anhängen, es erscheint die Fehlermeldung: "Dieser gemeinsame Ordner ist durch einen anderen Vorgang gesperrt. Bitte versuchen Sie es später erneut."

Hast Du dafür auch eine Lösung gefunden?
 

Matis

Benutzer
Mitglied seit
28. Mai 2015
Beiträge
735
Punkte für Reaktionen
9
Punkte
44
Problem gelöst: Dieses Phänomen tritt auf, wenn Universal Search abgestellt wurde und nicht läuft! Sobald es wieder läuft wird auch wieder fehlerfrei und schnell eingehängt!
 
Status
Für weitere Antworten geschlossen.
 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat