[05:01] <Jochen_wvdT> fair
[07:02] <dreamon> Moin. Wenn ich einen Usbstick mit FAT32 über Thunar einbinde, dann kann ich nicht darauf schreiben. 
[07:02] <dreamon> So ist er eingehängt /dev/sdd1 on /media/dreamon/USB type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2
[07:03] <dreamon> fat32 hat ja eigentlich keine Benutzerrechte. 
[07:27] <LupusE> die codepage sieht komisch aus. ist das deutsch? hat dien benutzer die uid 1000? warum ist das iocharset iso, wenn dann spaeter utf8 gesetzt wird?
[07:34] <dreamon> uid=1000(dreamon) gid=1000(dreamon) Gruppen=1000(dreamon)
[07:35] <dreamon> bezüglich iocharset bin ich überfragt. Er mountet das ja über Thunar
[07:37] <dreamon> LupusE, rw sollte doch eigentlich schreibbar sein?
[10:18] <tomreyn> dreamon: scheint mir ok zu sein. was geben denn "touch /media/dreamon/USB/test && rm /media/dreamon/USB/test" und "sudo touch /media/dreamon/USB/test2 && sudo rm /media/dreamon/USB/test2" aus?
[10:27] <NTQ> Das ist echt komisch. Wenn ich nemo mit gdb starte, dann stürzt er einfach nicht ab. Normalerweise wäre nemo jetzt schon mindestens 6 mal abgestürzt.
[10:31] <LupusE> dann nimm strace und eine nguten virenscanner.
[10:34] <NTQ> LupusE: Was soll ich mit einem Virenscanner?
[10:35] <dreamon> tomreyn, Keine Fehlermeldung. Das klappt. Keine Fehlermeldung!
[10:35] <LupusE> kaufen. die box in das regal stellen und jedem, der dich fragt erzaehlen, dass virenscanner manchmal helfen ungewoehnliches verhaltne zu erklaeren.
[10:37] <dreamon> tomreyn, Wenn ich aber mit Thunar was auf den Stick kopieren möchte geht das nicht.
[10:38] <NTQ> LupusE: Ähm, genau. Danke für diesen durchaus hilfreichen Tipp... Virenscanner sind normalerweise der Grund für komisches Verhalten. Deswegen hab ich keinen.
[10:40] <LupusE> NTQ: hier ist ein support channel. du hast eine situation geschildert. und ich habe dich lediglich darauf hingewiesen, dass du statt gdb auch strace nutzen kannst. desweiteren ist bekannt, das malware auf einem system auch erkennen kann, wenn sie zur laufzeit analysiert wird und dnan einfach nicht aktiv wird. wenn es dir lieber ist kannst du auch haendisch die MD5 Summen der betreffenden binaries 
[10:40] <LupusE> kontrollieren.
[10:41] <LupusE> wie ein scan eines datentraegers mit einem handelsüblichen virenscanner komishces verhalten erzeugen soll, das leuchtet mir nicht ganz ein.
[10:44] <NTQ> Ein einzelner Scan tut nichts schlimmes, aber so ein sich überall zwischenschaltender heuristischer Dank root-Zertifikat SSL-durchleuchtender Scanner eben schon. Oder wie Fefe sagt: Reinstes Schlangenöl.
[10:44] <NTQ> Abgesehen davon: Sollte nicht apt schon Prüfsummen bilden beim Installieren? Es sind aber definitiv Bugs in nemo, die ich etwas ausführlicher melden wollte und jetzt passiert es nicht. Das ist sehr ungewöhnlich.
[10:46] <dreamon> tomreyn, Danke habs glaube nun im Griff. habe in Thunar mit den Rechten als root was geändert glaube nun gehts.
[10:54] <tomreyn> dreamon: der erste befehlö lief ja als normaler user, nicht als root, es sei denn du warst schon als root eingloggt als du den ausführtest?
[10:56] <tomreyn> dreamon: wenn du nicht als root eingeloggt warst und beide befehle ohne fehlermeldung durchliegen dann kannst du offenbar auch als normalo-user schreibend auf dieses dateisystem zugreifen. weshalb es über die gui nicht ohne sudorechte geht wäre dann nochmal im nächsten schritt zu prüfen.
[11:30] <dreamon> tomreyn, Es ist genau so wie du schreibst. Muß leider weg.. Werde später nochmal dransitzen. im Terminal kann ich darauf schreiben. DANKE für deine Hilfe.
[11:35] <tomreyn> gern :)
[12:39] <stevieh> hmm... jetzt hängt der doofe tp edge nach nem resume unter 18.04 wieder... glotze geht an, aber kann keine Maus sehen und Tastatur auch nicht. Und netzwerk wohl auch nicht.
[12:56] <stevieh> wo find ich in 18.04 denn logs vom suspend resume? Bei meinem 17.10 heisst das noch pm-suspend
[12:56] <tomreyn> syslog + dmesg würd ich denken
[12:59] <stevieh> ne. da gab es extra files.
[13:02] <stevieh> doch, jetzt isses da
[13:05] <stevieh> https://paste.ubuntu.com/p/YWjXkSDywQ/
[13:05] <le_bot> Title: Ubuntu Pastebin (at paste.ubuntu.com)
[13:05] <stevieh> das sieht komisch aus
[13:08] <stevieh> Jun 15 14:21:39 tpedge /usr/lib/gdm3/gdm-x-session[954]: (II) UnloadModule: "libinput"
[13:08] <stevieh> das aber noch viel schlimmer... teufel, was macht die Möhre?
[14:07] <user03>  /j ##linux
[15:40] <stevieh> hmm... anscheinend ist es doch keine gute Idee, den gdm in X zu zwingen. Jetzt sieht es besser aus.
[15:40] <stevieh> strange
[16:23] <jokrebel> was wollte er uns damit mitteilen?
[20:31] <p01nt3r> nabend. es ist nicht normal, dass während der unattended updates die leisten sowie alle verknüpfungen auf meinem desktop nicht sichtbar sind, oder? ich kann aber z.b. ein terminal aufmachen.
[20:33] <k1l_> das klingt eher nach absturz von sachen. schau mal in die logs wie syslog oder die x logs, wenn es ein xserver noch ist
[20:34] <p01nt3r> die plattenauslastung ist unterdessen krass, die hdd-led leuchtet voll durch
[20:35] <p01nt3r> sind die updates durch, erlischt die led und der desktop zeigt alles an...
[20:36] <tomreyn> zeigt "df -h" in der spalte mit den % was oberhalb von 90?
[20:37] <p01nt3r> kann gut sein. also plattenplatz freigeben?
[20:38] <tomreyn> wenn's voll ist dann mach mal was platz, ja
[20:38] <p01nt3r> muss rebooten. sekunde
[20:41] <p01nt3r> tjoa also root ist bei 46% und /home bei 72%.