ubuntuusers.de

Hallo,

ein Freund kann unter Ubuntu 20.04 (aktualisiert) auf einem USB-Stick nicht schreiben (FAT-formatiert). Im Nautilus erscheint keinerlei Hinweis dass die Schreibrechte fehlen. Ein Reboot und erneutes Einstecken des Sticks brachte keinen Erfolg. Im parallel installierten Ubuntu 16.04 konnten die gewünschten Dateien problemlos auf den Stick kopiert werden. Insofern ist ein Defekt des Sticks wohl unwahrscheinlich.

Zu diesem Thema habe ich schon so einiges gelesen, z.B. dass es an den fehlenden Rechten bzw. am fehlenden "Besitz" liegt. Auch dass man /etc/fstab entsprechend bearbeiten könne. Leider steht nirgends eine einfache Methode wie ein Normalanwender ohne Terminalkenntnisse dieses Verhalten dauerhaft abstellen kann, sodass er mit Sticks umgehen kann wie er es von Windows gewohnt ist. Schließlich soll doch Ubuntu auch für Normalos eine Alternative sein.

Mit VeraCrypt scheint es ein ähnliches Problem zu geben wenn man einen Container einbindet, der auf einer anderen Partition des internen Laufwerks erstellt wurde. Zumindest bei ext4-Formatierung.

Möglicherweise sind in beiden Fällen die eingeschränkten Rechte ja sicherheitstechnisch sinnvoll und gewollt. Aber dann könnte das System beim Einstecken nach dem Admin-Pw fragen und mit entsprechend umfassenden Rechten einbinden.

Kennt jemand von Euch eine einfache Lösung?

Alternativ: wie sieht ein Eintrag in der fstab aus, der ein vereinfachtes Handling mit ALLEN USB-Datenträgern erlaubt?

Und wie geht das beim Einbinden von VeraCrypt-Containern reibungslos?

Danke & Gruß

andibl

Zeige

mount

Hallo andibl,

Ein Fat- 16/32 formatierter System (USB Stick) hat kein Rechtesystem ......

Gruss Lidux

Vielleicht ist's ja exFAT. Das hat auch kein Rechtesystem, es braucht aber Treiber. Es gibt die reverse-engineering-Lösung alter Samsung-Treiber und die neuere Lösung im Kernel. Jenachdem, welche man nutzt, gibt es unterschiedliche Probleme.

Wenn man im Terminal kopiert, ist eine aussagekräftige Fehlermeldung anzunehmen. Aber die mount-Abfrage ist schon erstmal richtig.

Hallo,

sorry für die verspätete Fortsetzung. Soweit ich das Folgende richtig verstehe, hat mein Freund unter Ubuntu 20.04 (aktualisiert) nur "read only"-Rechte. Seltsam ist allerdings, dass unter Ubuntu 16.04 der Schreibzugriff erlaubt ist. Bei einem anderen Stick hat er hingegen auf beiden Systemen Schreibrechte. Hat da jemand eine Erklärung?

sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,noexec,relatime,size=984016k,nr_inodes=246004,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=202636k,mode=755)
/dev/sda3 on / type ext4 (rw,relatime,errors=remount-ro)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
none on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=28,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=15879)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
/var/lib/snapd/snaps/core18_1988.snap on /snap/core18/1988 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/core18_1944.snap on /snap/core18/1944 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/gnome-3-28-1804_145.snap on /snap/gnome-3-28-1804/145 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/gnome-3-34-1804_24.snap on /snap/gnome-3-34-1804/24 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/gnome-3-34-1804_66.snap on /snap/gnome-3-34-1804/66 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/gtk-common-themes_1506.snap on /snap/gtk-common-themes/1506 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/gtk-common-themes_1514.snap on /snap/gtk-common-themes/1514 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/libreoffice_204.snap on /snap/libreoffice/204 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/libreoffice_205.snap on /snap/libreoffice/205 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/snap-store_433.snap on /snap/snap-store/433 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/snap-store_518.snap on /snap/snap-store/518 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/snapd_11036.snap on /snap/snapd/11036 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/snapd_11107.snap on /snap/snapd/11107 type squashfs (ro,nodev,relatime,x-gdu.hide)
/var/lib/snapd/snaps/vlc_2103.snap on /snap/vlc/2103 type squashfs (ro,nodev,relatime,x-gdu.hide)
/dev/sda4 on /daten type fuseblk (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=202632k,mode=700,uid=1000,gid=1000)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
/dev/fuse on /run/user/1000/doc type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
tmpfs on /run/snapd/ns type tmpfs (rw,nosuid,nodev,noexec,relatime,size=202636k,mode=755)
nsfs on /run/snapd/ns/snap-store.mnt type nsfs (rw)
/dev/sdb1 on /media/roland/0034-AC6F type vfat (ro,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)

Er wird nach dem Kopieren der Daten den Stick neu formatieren.

Gruß andibl

andibl schrieb:

Soweit ich das Folgende richtig verstehe, hat mein Freund unter Ubuntu 20.04 (aktualisiert) nur "read only"-Rechte. Seltsam ist allerdings, dass unter Ubuntu 16.04 der Schreibzugriff erlaubt ist.

/dev/sdb1 on /media/roland/0034-AC6F type vfat (ro,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)

Das hat mit Schreibrechten herzlich wenig zu tun, wenn man einen Datenträger read-only einhängt kann da logischerweise auch root nicht drauf schreiben...

Jetzt wäre natürlich interessant, warum das Teil nur ro eingehängt wird, hier wäre

dmesg

interessant.

Da habe ich wohl etwas vorschnell meinem Freund gesagt er soll den Stick neu formatieren. D.h. das Resultat von "dmesg" muss ich schuldig bleiben. Aber wer weiß, unter Ubuntu 16.04 hatte ich gelegentlich auch so ein Problem - möglicherweise dass selbe. Falls sich das unter Ubuntu 20 nochmal zeigt werde ich den Thread fortsetzen.

Best Dank für die Unterstützung

andibl schrieb:

Aber wer weiß, unter Ubuntu 16.04 hatte ich gelegentlich auch so ein Problem - möglicherweise dass selbe.

Das hat sich ja bald erledigt - Supportende ist im April 2021.