Το thread του Debian (v.7)

[jim_p]

Groups. Δεν τα εβαλα εγω, ο installer της διανομης τα εβαλε για το χρηστη μου το 2016 που ξαναεκανα εγκατασταση. Και παλιοτερα, πριν την επανεγκατασταση, ετσι ηταν αλλα τοτε δεν ειχαμε systemd.

[famous-walker]

Οτι λεει το ονομα, το μεν δινει προσβαση σε οπτικα μεσα, το δε σε floppy και συναφη, και παλιοτερα και σε συσκευες usb.

[Slammer]

είναι το group id, το δικό μου εχει 24 cdrom, αλλά όχι 25-floppy.... εχει μείνει από παλιά, αλλά δεν πειράζει.
Νομίζω ότι το ζητούμενο είναι το plugdev.
Επίσης μερικές φορές πρέπει να το κάνεις mount ως root μία φορά, και ενδεχομένως να αλλάξεις τα permissions του file-system στο root του usb (ειδικά αν το usb δεν ειναι fat)

[jim_p]

Debian Seeing Work To Support systemd-boot
https://www.phoronix.com/news/Debian...t-systemd-boot

[jim_p]

Accepted amarok 3.0.1-1 (source all amd64) into experimental
https://tracker.debian.org/news/1534...-experimental/

Η επιστροφη!

- - - Updated - - -

Debian 13 is Changing the /tmp Behavior
https://news.itsfoss.com/debian-13-tmp-mounting/
https://old.reddit.com/r/debian/comm..._tmp_behavior/

Τωρα εμαθα για το /var/tmp και του εριξα μια ματια. Σε μενα εχει κατι φακελους του systemd και μερικα αρχεια .bug, λογικα απο το reportbug. Να τα σβησω? Το /tmp το εχω στη ram απο το 2016 που εκανα εγκατασταση σε ssd.
Επισης, αν κατι εινια σε tmpfs, πως θα μενιε για 10 μερες στη ram? Εννοει πως θα μενει τοσο εφοσον δεν γινει επανεκκινηση?

[hammered]

Τρέχω εδώ και χρόνια ένα sid install το οποίο κάνω συνεχώς upgrade/dist-upgrade οπότε είναι current.
Είχα πάρα πολύ καιρό να συνδέσω usb stickάκι μέχρι σήμερα. Προφανώς κάτι έσπασε στο μεσοδιάστημα.

Το συνδέω, αναγνωρίζεται και γίνεται mount αν πατήσω πάνω του από το Thunar σαν κανονικός χρήστης. Αλλά δεν δείχνει αρχεία παρότι έχει τέτοια. Αντιγραφή αρχείου σε αυτό αποτυγχάνει με "permission denied". Η αντιγραφή γίνεται απρόσκοπτα με sudo. Ίδια ιστορία αν το κάνω mount μέσω του gnome disks manager.
Το mount γίνεται στο "/media/username/<hash>".

Αυτή την στιγμή μου διαφεύγει το όνομα της υπηρεσίας που είναι υπεύθυνη για το auto-mounting/user level mounting.
Υποθέτω ότι ο χρήστης μου δεν μετέχει σε κάποιο group που κοιτάει αυτή η υπηρεσία και για αυτό δεν έχει permissions.

Μπορεί κάποιος να με διαφωτίσει; Ξέρει κανείς σε ποιο group να προσθέσω τον χρήστη μου;

Ισως να μην βοηθαει, αλλα ο δικος μου ειναι σε αυτα

$ id jim
uid=1000(jim) gid=1000(jim) groups=1000(jim),7(lp),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),107(netdev)

Τελικά όχι. Ο χρήστης μου είναι σε όλα αυτά τα group (και κάποια επιπλέον) αλλά δεν έχει ούτε καν read permission στο automounted usb stick.
Δοκίμασα και με άλλο stick αλλά τα ίδια.
Κοίταξα και στο /etc/udev/rules.d/ αλλά δεν έχω κάτι εκεί, πέρα από έναν rule για αλλαγή I/O scheduler σε bfq.

[famous-walker]

Που το κανει mount;

[hammered]

/media/<username>/<disklabel>

[famous-walker]

Α το γραφεις και παραπανω. Μου ξεφυγε.

Μια χαρα μεχρι εδω. Τι δικαιωματα εχει ο /media/<username> ; Ποιον δειχνει ως ιδιοκτητη;

[hammered]

Α το γραφεις και παραπανω. Μου ξεφυγε.

Μια χαρα μεχρι εδω. Τι δικαιωματα εχει ο /media/<username> ; Ποιον δειχνει ως ιδιοκτητη;

Όταν μου έκανες την ερώτηση αμέσως πήγε το μυαλό στο ίδιο πράγμα.

Το έλυσα.

Έσβησα το /media/<username> ώστε το udisks2 να το ξαναδημιουργήσει όταν κάνει automount.

Και στις 2 περιπτώσεις το folder άνηκε σε root:root, η διαφορά ήταν στα file permissions. Το string ήταν το ίδιο αλλά την δεύτερη φορά είχε ένα "+" στο τέλος. Αυτό διαβάζω ότι υποδεικνύει ότι υπάρχουν και ACL permissions. Με ένα getfacl είδα ότι ο χρήστης μου είχε δικαιώματα βάσει του ACL.


Για μένα πρόκειται για bug του udisks2. Θα έπρεπε να ελέγχει κάθε φορά αν υπάρχουν τα σωστά file/acl permissions και να τα διορθώνει αυτόματα.