Ubuntu - Zugriff auf USB scheitert

Anders als der Threadtitel vermuten lässt, hat das Problem nix mit USB 
zu tun, sondern mit dem Dateisystem.

Wenn ich aufgrund fehlender diesbezüglicher Informationen raten sollte, 
würde ich sagen: die betreffenden Datenträger sind mit NTFS formatiert, 
und auf dem betreffenden System fehlt ntfs-3g  oder ein ausreichend 
aktueller Kernel mit nativem NTFS-Treiber, oder aber er ist vorhanden, 
aber der verwendete Automounter/Mount-Helper kennt den Treiber noch 
nicht.

OT: man kann in so Meldungen den Text in der Regel markieren und dann in 
den Forenpost kopieren – ist dann einfacher lesbar und benötigt nur ein 
Hundertstel der Ressourcen eines Bildes.

c-hater schrieb:
> Ähem, nein. Das ist keinesfalls zwingend der Fall, das Problem kann hier
> tatsächlich durchaus auch auf USB-Ebene liegen oder sogar noch tiefer.

Ähm doch. Diese Meldung besagt, dass der Kernel das Dateisystem nicht 
kennt, bzw.  die Automagie von mount, die bekannten Dateisysteme ohne 
die Angabe von ›-t typ‹ mounten zu können, hier fehlschlägt – das ist in 
der letzten Zeit häufiger bei NTFS und fehlendem nfts-3g der Fall. Beim 
manuellen Mounten würde man, einen entsprechend aktuellen Kernel 
vorausgesetzt, mit ›-t ntfs3‹ mounten können.

Fehler auf tieferer Hardwareebene, also im Bereich des USB-Treibers, 
äußern sich anders.

Moppi schrieb:
> [dämliche Trollabsonderungen]

Kannst du dämlicher Troll nich mal warten, bis der TE sein Problem 
gelöst hat? Deinen Dreck abladen und hoffen, dass jemand anbeißt, kannst 
du dann doch immer noch?

c-hater schrieb:
> Was aber ganz sicher der Fall ist: Wenn schon auf USB-Ebene oder gar
> darunter Bullshit gelesen wird, können Filesystem-Erkennungen eben
> WEGEN dieses Bullshits fehlschlagen.

Hier scheint aber zummindest das USB-Gerät als Massenspeicher erkannt 
worden zu sein, sowie dass der Datenträger partitioniert ist 
(/dev/sdb1).
Die Geräteebene scheint zu funktionieren...

c-hater schrieb:
> Ist mir nicht aufgefallen. Liegt wohl daran, dass bei Ubuntu (und darum
> ging es hier ja erklärtermaßen) NTFS immer mit drin ist.

Mag sein. Nur wenn’s einen aktuellen Kernel (größer 5.15, glaube ich) 
nutzt, wird es möglicherweise ntfs-3g nicht mehr per Default installiert 
haben, weil das da nicht mehr nötig ist. Allerdings muss man den 
Dateisystemtyp dann explizit angeben (wie ich bereits beschrieben habe), 
und wenn der hier genutzte Automounter/Mount-Helper/whatever das nicht 
tut, sondern sich auf die Magie von ›mount‹ verlässt, kommt es zu eben 
dieser Fehlermeldung. Da Win10 genannt wurde, von dem aus es gehen 
würde, ist davon auszugehen, dass es hier entweder um NTFS oder um ExFAT 
geht, wobei man mounts Magie bei ExFAT wieder funktioniert, AFAIR – was 
für mich die NTFS-Problematik als wahrscheinlicher erscheinen lässt. 
Aber TE könnte sich ja auch mal zum verwendeten FS äußern – eigentlich 
gehören solche Informationen in den Eingangsbeitrag.

c-hater schrieb:
> Was aber ganz sicher der Fall ist: Wenn schon auf USB-Ebene oder gar
> darunter Bullshit gelesen wird, können Filesystem-Erkennungen eben
> WEGEN dieses Bullshits fehlschlagen.

Nein. Wenn der USB-Treiber Bullshit macht, dann steigt usb_storage aus, 
und es gibt kein Devicefile. Wenn usb_storage Bullshit macht, gibt es 
ebenfalls kein Devicefile, oder aber eine seltsame Fehlermeldung beim 
Versuch, darauf zuzugreifen.

Ein Blick in journalctl -k (oder dmesg, wenn man die entsprechenden 
Rechte hat) ist dennoch nicht verkehrt, allerdings halt nicht aus dem 
genannten Grund.

c-hater schrieb:
> Du bist kein Programmierer, stimmt's?

Nicht hauptberuflich. Dafür nutze und ich seit einem Vierteljahrhundert 
nahezu ausschließlich Linux und administriere auch einige Kisten damit, 
und hätte daher durchaus einige Ideen, wie so Sachen zusammenhängen und 
welche Fehler sich wie auswirken können – aber das erhebt mich nicht auf 
deinen erhabenen Stand, oder? Nutzt du selbst überhaupt Linux, oder ist 
da nur ’ne schnelle Suchmaschinenabfrage schiefgelaufen? ;)

Wie auch immer – solange der TE sich nicht wieder mit den noch fehlenden 
Informationen meldet, bzw. idealerweise schon geschaut hat, ob er mit 
expliziter Angabe von ntfs3 oder dem Nachinstallieren von ntfs-3g zum 
Ziel kommt, geht’s hier eh nicht weiter, und die ganze OT-Diskussion ist 
nur ein weiterer Strich auf deiner „aber in meiner Vorstellung muss es 
so sein, also habe ich, und kein Anderer, Recht!!k“-Beitragsliste. 
Erlaube mir also, dass ich mich aus diesem Diskussionsteil zurückziehe.

c-hater schrieb:
> Dir fehlt ganz klar der Überblick

… und dir fehlen ganz klar Kenntnisse im Umgang mit Linuxsystemen, eben 
weil du’s praktisch allenfalls recht oberflächlich bedienst. Sonst würde 
dir klar sein, dass das vorliegende Problem, so, wie es beschrieben 
worden ist (der Punkt ist wichtig), nicht auf Fehler im USB-Subsystem 
zurückzuführen sein kann. So what?

Außerdem fehlen dir Kenntnisse über mich, sonst würdest du nicht blind 
irgendwelche Unterstellungen raushauen.

Vielleicht wär’s an dieser Stelle sinnvoll, mal die Tasten ruhen zu 
lassen und zu schauen, ob der TE nochmal vorbeischaut? Ich meine: der 
hatte schließlich ’n Problem, und hat nun erstmal einige Ansätze zur 
Lösung und zur weiterführenden Informationsgewinnung, sofern die Lösung 
noch nicht dabei war, und dem hilft unser Selbstdarstellungstheater grad 
vermutlich nicht weiter …

Frosch schrieb:
> Was bei mir nicht funktioniert,
> das SEGGER Embedded Studio zu installieren. Das verlangt root-Rechte und
> das Passwort, kein rankommen.

Da musst du wohl einen eigenen Faden aufmachen.

Toni schrieb:
> Vielen Dank, Jack!

Ich danke für die Rückmeldung :)

Karl schrieb:
> Ja, wenn du es vergessen hast, dann ist da kein rankommen.

Geht wohl eher darum, dass der User bei Buntu und Co. das Root-Passwort 
nicht kennt, weil es bei der Installation auf einen zufälligen Wert 
gesetzt wird. Lässt sich aber fix beheben: ›sudo passwd‹

c-hater schrieb:
> Das Problem ist nämlich: sieht man nur die Fehlermeldungen höherer
> Softwareschichten, kommt man leicht zu völligen Fehleinschätzungen des
> tatsächlichen Sachverhalts.

Äh, nein. In der abgebildeten Fehlermeldung steht haargenau das, was 
mount(8) auf der Kommandozeile ausgeben würde. Trotzdem wird es 
natürlich zusätzliche Details in den Systemlogs geben.

Frosch schrieb:
> Wenn das funktionieren würde, hätte ich hier nicht gefragt.

Wenn du ernsthaft gefragt haben wolltest, hättest du eine vernünftige 
Fehlerbeschreibung geliefert.

Frosch schrieb:
> Ich will den
> Thread nicht kapern. Tschüss

Das Problem des TE ist gelöst – wäre also kein Problem. So spricht halt 
nur alles für ’nen weiteren Troll: ominöses Problem hinrotzen, aber auf 
Nachfrage abblocken.

Frosch schrieb:
> Diese Empfehlung zeigt das: Lässt sich aber fix beheben: ›sudo passwd‹

Was genau geschieht denn bei ›sudo passwd‹ unter deinem Ubuntu 22.04 
LTS? Welche Fehlermeldung erscheint, welche Einträge im Journal erzeugt 
es?

Frosch schrieb:
> Du hast offensichtlich genau so wenig Ahnung von Linux wie ich, speziell
> unter Ubuntu 22.04 LTS.

Dem wage ich an dieser Stelle zu widersprechen. Offensichtlich weißt du 
gar nichts, Frosch. Ich weiß immerhin etwas.

Das Geschrei geht von dir aus, btw. – es ist ein hässliches, hohles 
Geschrei, das in den Ohren von jedem,  der helfen möchte, unglaublich 
schmerzt. Es klingt wie „Gehtnichtgehtnichtgehtnichtgehtnich“ – ganz 
scharf und schrill, völlig ohne eine tatsächliche Beschreibung des 
Problems.