Samba 4.15.0-1 error 255

Καλημέρα και καλή εβδομάδα.
Arch 5.10.74-1-lts με Cinnamon (και Nemo).
Έχω εδώ και πολύ καιρό στημένη Samba, που λειτουργούσε μια χαρά μέχρι πρότινος. Δύο υπολογιστές, Α και Β διαβάζουν και αντιγράφουν μεταξύ τους τα αρχεία μέσα στους κοινόχρηστους φακέλους, και επίσης ο Β τυπώνει στον εκτυπωτή που είναι συνδεδεμένος (USB) στον Α.
Στις 21/9 απ’ ότι λέει ο pacman, έγινε αναβάθμιση της samba στην έκδοση του τίτλου.
Χτες το μεσημέρι πήγα να κάνω κοινόχρηστο το φάκελο Music, και άρχισε ο Γολγοθάς :
(το error της φωτογραφίας, άσχετα αν δείχνει άλλο φάκελο, θα εξηγήσω παρακάτω)


Η samba συνεχίζει να δουλεύει για τους ήδη κοινόχρηστους φακέλους, δεν μπορώ να κάνω κοινόχρηστο κάποιον άλλο φάκελο, μέσα στο /home, με τα ίδια δικαιώματα με τους άλλους.
Επίσης, απενεργοποίησα την κοινή χρήση του Pictures, και πλέον δεν ενεργοποιείται ξανά.
Το ψάξιμο για error 255 οδηγεί στη σελίδα της samba στο wiki, στο κομμάτι “Enable usershares”, σε οδηγίες οι οποίες έχουν ακολουθηθεί κατά γράμμα, η Samba δουλεύει, και το testparm δείχνει οκ.

Το μόνο που μου κάνει εντύπωση είναι το ότι στο testparm δεν φαίνεται η γραμμή

usershare path = /var/lib/samba/usershares

η οποία όμως υπάρχει στο smb.conf. (Αναρωτιέμαι αν θα έπρεπε να φαίνεται, μιας και απ’ ότι διαβάζω δεν είναι η default ρύθμιση).
Έψαχνα για ώρες χτες. Δεν βρήκα κάτι άμεσα σχετικό και πρόσφατο με το θέμα, ούτε γενικά στο internet, ούτε και κάποια αναφορά για σχετικό bug στο wiki του Arch.
Αυτό που βρήκα στον υπολογιστή μου, είναι ότι αφού γίνει η προσπάθεια κοινής χρήσης ενός φακέλου και βγει το error, δημιουργείται μέσα στον συγκεκριμένο φάκελο ένα αρχείο log.net, με το εξής περιεχόμενο :

net usershare add: share name /home/george/downloads contains invalid characters (any of %<>*?|/+=;:",)

Επειδή στο φάκελο Music έχω χιλιάδες αρχεία, είπα μήπως κάποιο filename δημιουργεί το πρόβλημα. Δεν είναι έτσι. Το κάνει σε οποιοδήποτε φάκελο, ακόμα και σε άδειο!
Είπα να γράψω το θέμα χτες το βράδυ, αλλά επειδή με είχε κουράσει και εκνευρίσει για σχεδόν κανα 6άωρο, το άφησα να το ξαναδώ σήμερα με καθαρό μυαλό.
Το πρωί σκέφτηκα να κάνω downgrade τη samba.
Μετά το downgrade του προγράμματος, το testparm βγάζει αυτό :


το οποίο δυστυχώς δεν έχω τις γνώσεις να το φτιάξω.
Υπάρχει καμιά ιδέα για το τί προκαλεί το πρόβλημα στην τρέχουσα έκδοση της samba, και πώς διορθώνεται;
Αν όχι, μπορεί κάποιος να με βοηθήσει να κάνω σωστά το downgrade;
Συγνώμη για το σεντόνι πρωί πρωί, και ευχαριστώ προκαταβολικά για τις απαντήσεις.

Update :
Μπακαλοworkaround :
Μετά από ώριμη σκέψη (:joy:), είδα ότι στο
/var/lib/samba/usershares
υπήρχε ένα αρχείο .txt με το όνομα documents, με περιεχόμενο το εξής:

#VERSION 2
path=/home/george/Documents
comment=
usershare_acl=S-1-1-0:F
guest_ok=y
sharename=Documents

(Documents είναι ο μόνος φάκελος που μου απέμεινε κοινόχρηστος).
Έφτιαξα με nano ένα αρχείο με το όνομα pictures, και αντέγραψα μέσα το περιεχόμενο του documents, αλλάζοντας σε “Pictures” όπου υπήρχε η λέξη “Documents”
Μετά, μιας και το νέο αρχείο βγήκε με λουκέτο, έκανα
sudo chown george:george pictures
και το λουκέτο εξαφανίστηκε.
Έκανα το αντίστοιχο και για το φάκελο Music
Μετά από επανεκκίνηση, η κοινή χρήση αυτών των φακέλων δούλεψε κανονικά.
Επίσης, δούλεψε και με τη μέθοδο από τερματικό :
(sudo net usershare add…) κλπ
Οπότε το αρχικό ερώτημα αλλάζει σε :
Τι εμποδίζει το create share του Nemo να δημιουργήσει αυτά τα αρχεία;
(ο χρήστης είναι στο group sambashare).

1 «Μου αρέσει»

Νομίζω ότι το πρόβλημά σου σχετίζεται με αυτό παρακάτω, είναι από το forum του Manjaro και αναφέρεται σε samba με nautilus, παρ’ όλ’ αυτά έχετε κοινά σημεία, ειδικά στα περιεχόμενα του log.net. Μετάφρασε το post #20 από τα Γερμανικά για να καταλάβεις, φτιάξανε και ένα patch για το nautilus-share.

1 «Μου αρέσει»

Σ’ ευχαριστώ πολύ για την απάντηση. Αρχικά φαίνεται πως όντως υπάρχει θέμα, και δεν έκανα κάποια πατάτα εγώ.
Αυτό που κατάλαβα είναι πως ακόμα και αν δεν φταίει το nautilus-share (nemo-share στην περίπτωσή μου), το θέμα πάει στο smbclient.
Αλλά, ακόμα και να φταίει το *-share, επεμβαίνουν στο PKGBUILD πακέτου που είναι στα Packages, και όχι στο AUR, πράγμα που δεν έχω διανοηθεί καν πως γίνεται.
Σε κάθε περίπτωση, αν είναι έτσι τα πράγματα, σηκώνω τα χέρια ψηλά, και βολεύομαι με το net usershare add…, που, με ολόκληρο το path, σ’ εμένα δούλεψε.

1 «Μου αρέσει»

Το πρόβλημα απ’ ότι κατάλαβα είναι στον διακόπτη -l, ενώ με τον διακόπτη –long δουλεύει, το patch αντικαθιστά αυτό στην ουσία. Όπως και να έχει σίγουρα θα βγει fix, οπότε μπορείς να περιμένεις μέχρι τότε.

1 «Μου αρέσει»

Εκτός θέματος αλλά βλέποντας το δικό σου πρόβλημα, συνεχίζω να γκρινιάζω για αυτές τις “ανορθογραφίες” του linux, αυτές τις αδιανόητες χαζές και ηλίθιες εμμονές που μόνο κακό κάνουν και μας κάνουν την ζωή πιο δύσκολη!
Μα είναι δυνατόν εν έτη 2022 να μην γίνετε αυτοματοποιημένα με κλικ, επόμενο, κλικ, τσεκ αυτό, οκ, τέλος η διαδικασία sharing και να μην έχεις εικόνα από το τοπικό σου δίκτυο, εκτυπωτές χωρίς να χρειάζεται να “γίνεις” προγραμματιστής!!!

2 «Μου αρέσει»

@astrolavos1998
Είναι το ακριβώς αντίθετο από αυτό που βλέπεις.
Εξηγώ.
Αν όλα γινόντουσαν μόνο με κλικ κλπ κλπ τότε η “ανορθογραφία” του κώδικα δεν θα μπορούσε να παρακαμφθεί ή διορθωθεί, βλέπε windoz. Οπότε θα έπρεπε να περιμένεις διορθώσεις ή αναβαθμίσεις και δεν θα μπορούσες να δουλέψεις.

On topic
Για το συγκεκριμένο πάντως θέμα έχω πιαστεί αδιάβαστος. Θα ρίξω μια ματιά οπωσδήποτε.

EDIT
Το bug που δεν είχα ποτέ διαβάσει ότι υπάρχει (δεν χρησιμοποιώ usershares) φαίνεται ότι είναι παλιό (~2018).
Η λύση που δίνουν σε debian-forum είναι η ακόλουθη
sudo chmod 1775 /var/lib/samba/usershares/
sudo chmod +t /var/lib/samba/usershares/

Αυτό σημαίνει ότι είναι θέμα permissions (+t) και υποθέτω ότι γιαυτό δεν φέρνει το path η testparm

[off topic]
Το να υπάρχει εφαρμογή, που να κάνει αυτοματοποιημένη την διαδικασία για την διασύνδεση Η/Υ, εκτυπωτών και γενικότερα συσκευών με οποιαδήποτε λειτουργικά συστήματα που είναι πάνω στο ίδιο τοπικό δίκτυο, αλλά με κάποια διεπαφή γραφικής απεικόνισης, ΣΕ ΚΑΜΙΑ ΠΕΡΙΠΤΩΣΗ ΔΕΝ το καθιστά χωρίς δυνατότητα παράκαμψης και διόρθωσης λαθών, “ανορθογραφιών” του κώδικα από μέρους της ομάδας δημιουργίας του και της κοινότητας του Linux.
Πάντα μιλάμε για ανοιχτού κώδικα εφαρμογές.
Μακάρι να είχαμε 50 διανομές Linux αλλά να μην είχαμε τέτοιου είδους προβλήματα και “αστοχίες”.
Προσωπική άποψη, πιστεύω και επιμένω πως πρέπει να δοθεί περισσότερο βάρος από την κοινότητα του Linux προς αυτήν την κατεύθυνση. Λιγότερες διανομές, περισσότερη αυτοματοποίηση για τον απλό χρήστη και αμφίδρομη διαδραστικότητα του λειτουργικού συστήματος Linux με τον απλό χρήστη!
[/off topic]

Δυστυχώς ούτε αυτό δούλεψε…