USB-Laufwerken feste Bezeichung zuweisen?

[Kurt-oe1kyw]

Probier bitte mal bei 31 = die Kennung einzutragen ohne der letzten 0
und bitte bei 32 = die Kennung eintragen ebenfalls ohne der letzten 0
die gehört offenbar nicht dorthin.
Lass die Kennung enden mit EF bzw E0 und nicht wie bisher mit EF0 und E00.

 

[BigRonin]

die gehört offenbar nicht dorthin

Ich denke die letzte "0" gehört da hin!

Das was lsusb anzeigt sind die echten Seriennummern des USB-Kontrolers ... die Einträge in der 'usbno_guid.map' bestehen 'immer' aus der echten Seriennummer PLUS der angehängten "0".

Ganz einfach zu überprüfen ... einen der beiden Einträge "31" oder "32" löschen ... Festplatte neu anschließen, 'usbno_guid.map' kontrollieren.

Was mit noch einfällt ... es gibt eine weitere Datei die "vermutlich" bei der Vergabe der ID eine Rolle spielt :
'/usr/syno/etc/usbdev.conf'



Die Angabe in den eckigen Klammern ist die Vendor-ID : Produkt-ID : Seriennumer
gefolg von der guid = Seriennummer PLUS angehängter "0"
und dem zugeordneten Gerätenamen.

Wie gesagt ... ob und wie diese Datei auswirkungen hat ... kann ich zur Zeit nicht sagen.

 

[Kurt-oe1kyw]

Ich denke die letzte "0" gehört da hin!

Ja stimmt, ich habe gerade noch mal bei mir Nachgesehen, die enden bei mir ALLE mit 0 als letzten Eintrag, selbst die Dockingstation. Über usbdev.conf kann ich leider gar nichts sagen, ich habe immer nur die usbno_guid.map Datei editiert.

 

[heiko228]

Ich verstehe dann gar nicht, warum das bei euch funktioniert und bei mir nicht. Liegt das vielleicht doch am Gehäuse selber? Wäre ärgerlich.

 

[heiko228]

Ich habe mir mal heute ein neues externes Gehäuse gekauft. Von der Firma UGREEN. Mal gucken, wie sich das ganze dann verhält. Ich melde mich diesbezüglich dann später.

 

[heiko228]

Also...mit dem Zuweisen der Bezeichnungen würde tatsächlich jetzt so klappen ..... aaabbbeerrr...immer wenn ich mit der Zeitschaltuhr den Strom weg nehme und wieder später zuschalte dann bleibt die HD aus. Ich muss dann immer in den Keller und auf den Power Button drücken.....was für ein Mist......hmmmmmm.....

 

[Kurt-oe1kyw]

Prima dass es jetzt mit der eigenen Vergabe der usbshare Bezeichnung klappt und wegen Zeitschaltuhr, ja entweder mit Uhr und Kellerrunde, oder du lässt die externe HDD an. Die sollte aber autom in hibernation gehen wenn sie länger nicht angesprochen wird.

 

[heiko228]

Ich bin noch am überlegen, ob das Sichere Auswerfen vom NAS nach dem Backup genau so gut und sicher ist wie die HD direkt vom Strom zu trennen bezüglich Ransomware und andere böse Dingen.

 

[heiko228]

Ich habe eine Antwort vom Support erhalten. Darauf bin ich auch nicht gekommen. Das sichere Auswerfen der Festplatte/Medium reicht nicht wirklich, zum Beispiel um das Verschlüsseln durch Ransomware zu verhindern, aus. Wenn die Schadsoftware so designed ist, dass die NAS herunter gefahren und neu gestartet wird, dann ist die HD wieder gemountet und kann verschlüsselt werden. Nur ein Beispiel. Die Frage ist, welche Voraussetzung muss gegeben sein, dass die NAS neu gestartet werden darf. Eigentlich Root/Admin Rechte. So weit zu gemounte Medien.

 

[Horst22]

Bei mit BTRFS formatierten USB-Festplatten gibt es bei in /usr/syno/etc/usbno_guid.map geänderter Nummer folgendes Problem:
Wenn man die Platte mal ordnungsgemäß "entfernt", absteckt und danach wieder ansteckt, dann wird das Dateisystem nicht mehr erkannt. Um die Platte wieder verwenden zu können, kenne ich bisher nur einen Weg: Diskstation neu booten. Bei anderen Dateisystemen (z.B. NTFS) scheint es kein solches Problem zu geben. Stand: DSM 7.1-42661 Update 1

 

[ottosykora]

also das habe ich nie getestet, ist aber interessant und gut zu wissen
Wir hatten wohl bisher kein Bedürfnis gehabt die ext Platte mit btrfs zu formatieren

 

[Horst22]

Bei mit BTRFS formatierten USB-Festplatten gibt es bei in /usr/syno/etc/usbno_guid.map geänderter Nummer folgendes Problem:
Wenn man die Platte mal ordnungsgemäß "entfernt", absteckt und danach wieder ansteckt, dann wird das Dateisystem nicht mehr erkannt. Um die Platte wieder verwenden zu können, kenne ich bisher nur einen Weg: Diskstation neu booten. Bei anderen Dateisystemen (z.B. NTFS) scheint es kein solches Problem zu geben. Stand: DSM 7.1-42661 Update 1

Update: Nach dem zuück zu wechselnden USB-Nummern und wieder vor zu de festen Nummern geht es jetzt plötzlich auch bei btrfs ohne Probleme. Keine Ahnung warum ...

 

[garack]

Hmm bei mir (DS3018xs DSM 6.2) wird kein Laufwerk außer das was immer dran ist (Laufwerk Nummer 1) mehr erkannt.

In der usbno-guid.map steht folgendes: Alles wie bisher es wurden auch keine anderen USB Geräte angesteckt, nur..was ist die Nummer 2 ??

 

[garack]

Hmm bearbeiten kann ich nicht mehr. Durch einfachen Reboot wurden die Platten wieder erkannt. Synology und USB....


Große Frage ist ob das Ganze auch mit DSM 7 so läuft. 6 hat ja EOL im Sommer 2023 ...

 

[Kurt-oe1kyw]

Also mit der jetzt gerade aktuellen DSM Version 7.1.1-42962 Update 1 funktioniert es nach wie vor wie gewohnt ohne Probleme.

 

[Horst22]

Update: Nach dem zuück zu wechselnden USB-Nummern und wieder vor zu de festen Nummern geht es jetzt plötzlich auch bei btrfs ohne Probleme. Keine Ahnung warum ...

Inzwischen habe ich das Problem mit dem nicht erkannten BTRFS noch etwas durchleuchtet. Ich denke, es hat keinen Zusammenhang zu der hier beschriebenen Zuordnung einer festen Bezeichnung!
Das Problem tritt in folgendem Szenario auf: Zwei (oder mehr) externe USB-Festplatten, die mal beide gleichzeitig betrieben werden und dann mal einzeln angeschlossen werden. Und dann noch ein laufender Docker-Container, der ein Verzeichnis auf einer der USB-Platte als Volume eingebunden hat. Irgendwann beschwert sich dann der BTRFS-Treiber mit "duplicate device fsid:devid for <DevGUID> old:/dev/usb1p1 new:/dev/usb2p1" (in dmesg zu sehen) und "Systemsteuerung/Externe Geräte" meldet "Dateisystemtyp nicht unterstützt". Das Auswerfen des Laufwerks scheint dann nicht vollständig zu funktionieren. Das Kommando "btrfs version" liefert v4.0 auf meinem "DSM 7.1.1-42962 Update 1".
Gemäß https://github.com/markdumay/synology-docker/issues/22#issuecomment-968371632 ist es wohl eine von Synology gepatchte Version des BTRFS-Treibers. In https://btrfs.readthedocs.io/en/latest/CHANGES.html#btrfs-progs-5-11-2021-03-05 heißt es für die v5.11 u.a.: "fix duplicate mount path detection". Möglicherweise hätte diese und neuere Versionen des BTRFS-Treibers das Problem nicht mehr. Wenn ich den Docker-Container vor dem Auswerfen beende und auch sonst kein Prozess mehr zugreift, dann scheint es auch bei v4.0 keine Probleme zu geben.

 

[ottosykora]

also ja, es ist bekannt, dass die btrfs Versionen in der Syno nicht mit den neusten übereinstimmen. Darum müssen für einige Aufgaben dann auch ältere Linux Distros gesucht werden damit alles funktioniert.

 

[*kw*]

Ich bin gerade über das Thema gestolpert und habe da seit Jahren eine ganz andere Lösung für mich:

Ich stecke nur EINE USB-Platte an, dann erscheint sie in der Systemsteuerung unter "Freigegebene Ordner" als "usbshare1". Wähle den "Ordner" aus > Bearbeiten > Name...und gebe demselbigen einen, z.B. intenso35 und speichere das ganze. Danach werfe ich die Platte aus.

Diesen Vorgang wiederhole ich mit jeder gewünschten Platte und sobald künftig eine "betitelte" Platte einstecke, erscheint sie sofort mit Ihrem Namen.

Hier gleichzeitig meine 2.5" und 3.5" Backup-Platten und die sind bspw. beim Hyper-Backup auch so als Ziel erkennbar

 

[plang.pl]

Mach ich genauso

 

[ottosykora]

ja, das machen alle so, bis es mal mehrere Platten braucht, also mehr als USB Steckdosen. Genau dann kommt das alles durcheinender.