#10 Egyébként semmilyen tesztet nem végeztél (pl. dmesg), úgyhogy, semmit nem tudunk arról, mi lehet a problémád mögött. Az ok.

... RAM rendben már?

#6 Úgy látszik a Linux Mint (legalábbis a 18.1) hadilábon áll az USB-k kezelésével. Ez a readonly dolog is durva bug, az meg még durvább, hogy egy USB 3.0-ás pendrive-ra 2-3 MB/s sebességgel írja a nagyobb fájlokat.

Ha a fórumon a problémáidra rákeresel, lyukra futsz:

Csak nálad áll hadilábon a Nemo fájlkezelő az USB eszközök kezelésével

Az írás sebessége más kérdés, mármint olyan szempontból .. hogy az állítás nem igaz. :-)
És nem ez volt az eredeti gond, olyan szinten nem, hogy erről eddig szó sem esett.

-----

A Nemo a Mint fájlkezelője. Ha nálad más van, pl. Nautilus, akkor "killall nautilus".

A Nemo nem Linux Mint fájlkezelője. A Nemo csak a Cinnamon asztali környezet fájlkezelője.
https://en.wikipedia.org/wiki/Nemo_(file_manager)
Az általad javasolt parancs lehet, nálad megoldja a problémát (ami csak a tied),
de az általad linkelt oldal dátuma igen régi: December 19, 2013
https://sharadchhetri.com/2013/12/19/how-to-fix-read-only-usb-pen-drive-...
Nem gondolod, nálad, a te rendszereddel van hiba, másban, máshol van durva bug?

#9 Erre a másik kérdésre is válaszolva: semmi hiba. Egyik Mintnél sem: 18.x, 19.x.

#12 FAT32 / USB eszköz: Szóval csak nálam? Akkor olvasgass: Link

Ha jól emlékszem, azt írtam, itt a fórumon nem jelzett senki. :-)
Mindentől függetlenül nem Cinnamon vagy Nemo hiba, ezt is próbáltam jelezni. Te is írod a Nautilust (Gnome alkalmazás) illetve, azt is (atime-ak) hogy „ami a fájlkezelőd, azt lődd ki”, tehát bármi lehet (Thunar, Doplhin, PCManFM, Caja, stb.) ..., de mindeközben az a következtetésed, hogy Linux Mint hibáról van szó (18.3). Ez így nem igaz.
És azt is jeleztem, csak kijelentesz valamit, de mögötte semmi nincs. Például egy dmesg kimenet, amiből a sötétbe valami fény szivárogna.
Akármi lehet, én GVFS-re gyanakszom ..., nem tudom, mi lenne a nálad jelentkező hiba lényege, mögöttes oka, de ez is benne a találatokban. Viszont fenntartom magamnak a jogot, hogy a tesztek és  kimenetek (naplók) stabil lábaira állva legyen valami kimondva, véleményezve. :-)
Azt is jeleztem, nálam, a rendszereimen nincs ilyen hiba. FAT32-vel is teszteltem. Én csak az igazat írtam (hülyeségeket meg nem is tudom ki), viszont a nálad jelentkező hibát helyetted nem tudom tesztelni. :D
Ha lenne teszt kimenet, akkor még javítást is ajánlanánk. Az nem kell? :-)
FAT32, NTFS, EXT4 teszt egyaránt lehet. És utána, a befűzésnél egy, egy dmesg kimenet.
Még valami. Biztosan USB v3.0 csatiba dugtad az eszközt?

Másolás, áthelyezés sebessége

A 64 bites ubuntu alapu rendszerek a rendszermemóriát használják puffernek,ami általában előnyös, de nagyobb fájlok külső adathordozóra való átmásolásánál hátrányos,mert a biztonságos adatátvitel érdekében, miután nagy sebességgel egészben vagy részben (memória nagyságától függöen) bemásolta a memóriába a fájlokat,onnan lassan irja ki a külső adathordozóra, majd másolás végén a szinkronizálás, és ami igazán lassitja a folyamatot, hogy a memóriát meg kell tisztitani a bemásolt adatoktól ami nagyobb memória kapacitás esetén hosszadalmas.
Ezért ezt a kapacitást előre lecsökkentve (mértékét tesztek által az adott hardverhez igazitva) megszüntetjük a memória "piszkos fájlokkal" való telitődését,igy felgyorsitjuk a fájlok másolását.
https://linuxmint.hu/comment/13504#comment-13504

Ez nemcsak az Ubuntu-alapú rendszereknél van így. Ebben tévedsz. Itt
https://linuxmint.hu/comment/13483#comment-13483
a Red Hat-ról is szó esik. A kernelről van szó általában ... .
Amit te jeleztél, az viszont 1-2MB/s, nagyon kevés (USB v3.0). Más oka lehet inkább.
A bejegyzésben emített módszerrel gyorsabb lett nálad is a másolás? Kipróbáltad? Mennyivel?

Drága kimarite!

Miért írsz ekkora hülyeségeket?!

"Csak nálad áll hadilábon a Nemo fájlkezelő az USB eszközök kezelésével"

Szóval csak nálam? Akkor olvasgass: Link

"A Nemo nem Linux Mint fájlkezelője. A Nemo csak a Cinnamon asztali környezet fájlkezelője."

Most már tudom. Köszönöm.

"Erre a másik kérdésre (SEBESSÉG) is válaszolva: semmi hiba. Egyik Mintnél sem: 18.x, 19.x."

Akkor frissítem a memóriádat: Link

(A RAM már rég megoldva, ahogy jeleztem is anno.)

#14 Mindkét hiba egy rakás másik júzernél is jelenkezett világszerte, szóval nagyon is valósak, nemcsak nálam vannak.
Te viszont kimondatlanul is lehülyéztél (indokolatlanul, lásd az előző mondatot), amit nem szívelek. Ennyi.
A Nemo problémán ne rugózzunk, nagyjából megoldva, jobbat te sem fogsz tudni, gyanítom.

Egy rakás másik felhasználónál, de nem a Linux Mint hibája. Utóbbit állítottad. Nem igaz.
Ahogy érzed :-), én nem mondtam, és nem is gondoltam, hogy hülye vagy. De a viselkedésed most már erre vall és a problémáddal addig nem is érdemes foglalkozni, amíg minimum egy dmesg kimenet nem érkezik tőled. Illetve a tesztek (FAT32, NTFS, EXT4 ... BRTFS). A problémádon a tesztek nélkül nem tudok segíteni, ebben az egyben igazad is van. Más sem segíthet. De ez eléggé Windowszos felfogás (a részedről): van egy problémám , szar, ahogy van az egész, de, ha a fene fenét eszik, akkor sem teszek meg semmit a megoldásért.
Hogy mit szívelsz, mit nem, a te dolgod, én meg külösebben nem vagyok kíváncsi senki világnézetére ..., de a felfogásod egyik fórumon sem szívelik. A prolémád magától nem lesz megoldva. Esetleg egy frissítés ... (hátha). :-D
Én nem rugózom semmin:-)). Egy fórumon vagy és válaszolunk neked, ez a normális. Kimeneteket, teszteket kérünk, ha nem is feltétlen a hamis állításodra válaszként, hanem, éppen azért, hogy megoldjuk a problémád. Ha nem tetszik, menj, senki nem tart vissza. :-))
A profilodnél ez szerepel: „Ismeretszerzés”. Igaz, vagy nem igaz? :-)

AZ USB másolás-sebességgel kapcsolatban: az /etc/sysctl.conf file-ba ezt a két sort írtam bele:
vm.dirty_bytes = 104857600
vm.dirty_background_bytes = 52428800
Emellett vannak a gyatra sebességek.

Induljunk az elejéről. Az eredeti állapotról volt szó, erre most - szerintem elég váratlanul - kiderül, változtattál a beállításokon ..., és így nem jó. Az eredeti állapot milyen sebességet mutatott? Mint az eredeti bejegyzés leírja, neked kell megtalálnod a megfelelő beállítást (sysctl.conf), így javaslatom nem lehet. És túlzottan nem is foglalkoznék a problémával ..., mert esetleg még más dolog is kiderül, ami nem a rendszer eredeti állapotára vall. Tremészetesen mindezt tudnunk kéne, és nem kellett volna elárulnod korábban. De.

Konkrét beállításokat teszt által tudsz kivitelezni, mert a beállítás általában hardver függő.

Forrás: https://linuxmint.hu/comment/13498#comment-13498

Te konkrétan egy, az egyben másoltál és azt reméled, így jó lesz. Hát nem.

Mindkét hiba egy rakás másik júzernél is jelenkezett világszerte, szóval nagyon is valósak, nemcsak nálam vannak.

Te viszont kimondatlanul is lehülyéztél (indokolatlanul, lásd az előző mondatot), amit nem szívelek. Ennyi.

A Nemo problémán ne rugózzunk, nagyjából megoldva, jobbat te sem fogsz tudni, gyanítom.

AZ USB másolás-sebességgel kapcsolatban: az /etc/sysctl.conf file-ba ezt a két sort írtam bele:
vm.dirty_bytes = 104857600
vm.dirty_background_bytes = 52428800

Emellett vannak a gyatra sebességek.

Egy USB eszköz

-- korábban

mount
[...]
/dev/sdb1 on /media/kim/SBLIVE type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)

Minden jogom megvan írni és olvasni. Létrehoztam benne egy fájlt (Caja fájlkezelő / MATE). Listázom:

ls -la /media/kim/SBLIVE/
összesen 8
drwxr-xr-x  2 kim  kim  4096 máj   22 21:12 .
drwxr-x---+ 3 root root 4096 máj   22 21:11 ..
-rw-r--r--  1 kim  kim     0 máj   22 21:12 1.txt

... formázom a GParted segítségével FAT32 fájlrendszerre. Új partícióstábla (msdos) létrehozása után.

Megvan.

-- most

mount
[...]
/dev/sdb1 on /media/kim/1247-6ECE type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)

Minden jogom megvan írni és olvasni. Létrehoztam benne egy fájlt (Caja fájlkezelő). Listázom:

ls -la /media/kim/1247-6ECE/
összesen 8
drwxr-xr-x  2 kim  kim  4096 máj   22 21:22 .
drwxr-x---+ 3 root root 4096 máj   22 21:22 ..
-rw-r--r--  1 kim  kim     0 máj   22 21:22 2.txt

Megnéztem egy videót. Íme: https://www.youtube.com/watch?v=F4lAlb74mGs
(a kérdező linkelt találatai között találtam)

Megcsinálom, amit a vídeóban látok (példa: sdb - ez van nálam!)

sudo su -

A

df -Th

parancs kimenete (példa):

Fájlrendszer   Típ.     Méret Fogl. Szab. Fo.% Csatol. pont
udev           devtmpfs  3,9G     0  3,9G   0% /dev
tmpfs          tmpfs     786M  9,3M  776M   2% /run
/dev/sda1      ext4      106G   44G   57G  44% /
tmpfs          tmpfs     3,9G  159M  3,7G   5% /dev/shm
tmpfs          tmpfs     5,0M  4,0K  5,0M   1% /run/lock
tmpfs          tmpfs     3,9G     0  3,9G   0% /sys/fs/cgroup
tmpfs          tmpfs     786M   56K  786M   1% /run/user/1000
/dev/sdb1      vfat      1,9G  4,0K  1,9G   1% /media/kim/1247-6ECE # példa!

A fenti kimenet szerint megszűntetem a befűzést:

umount /media/kim/1247-6ECE

A fenti kimenet szerint javítást eszközlök (FAT32):

dosfsck -a /dev/sdb1

A parancs kimenete:

fsck.fat 4.1 (2017-01-24)
/dev/sdb1: 2 files, 1/485006 clusters

... a videóban látott *.REC fájl (amit töröl a vlogger) nem keletkezik a javított partíción (sdb1), de nem is volt hiba az eszközzel.

Az sdb1 partíció példa. Esélyes, hogy a te rendszered alatt más lesz a df -Th kimenet, erre figyelj!

-----

Egy másolás teszt. Az eszköz USB v2.

rsync -ah --progress /home/kim/Letöltések/xubuntu-19.04-desktop-amd64.iso /media/kim/1247-6ECE/
sending incremental file list
xubuntu-19.04-desktop-amd64.iso
          1.59G 100%    6.57MB/s    0:03:50 (xfr#1, to-chk=0/1)

A másolás sebessége átlagosan 6MB/s. Alap rendszer.