Ciao a tutti,
Ho preparato una LAN con VNC tra due mini-pc, entrambi con Fedora 42 lxde.
La condivisione funziona, ma riscontro un inconveniente con i permessi sul server.
Sul server, non posso far partire smplayer. Se provo da terminale mi dice “permesso negato”.
Se provo a fare gli aggiornamenti con dnfdragora si rifuta di farli perchè dice che non sono autorizzato.
Qualche idea per rimediare?
A me questo non succede. Quando il cliente è collegato gli aggiornamenti funzionano.
Se scrivo nel terminale: sudo dnf upgrade ottengo l’elenco dei pacchetti da installare.
Ti chiedo: quando ti colleghi inserisci una password per autorizzare la connessione?
Sì. Inserisco una password per autorizzare la connessione del client.
Sul server, per aprire una sessione con l’utente usuale, no. Ho sempre fatto anche gli aggiornamenti con dnfdragora senza inserire nessuna password.
Ho visto che posso fare gli aggiornamenti sul server dalla sessione aperta sul client, ma questa dipendenza dal client non mi piace.
Per l’esattezza, se tento di fare l’aggiornamento, ottengo una finestrella che mi dice:
Error in status DNFDragoraStatus.RUN_TRANSACTION on RunTransaction
org.rpm.dnf.v0.Error:Not authorized
Ho visto ora che da terminale funziona anche per me. E’ solo da dnfdragora che qualcosa non funziona.
Per smplayer, se tento di aprirlo dal menù di avvio non succede niente. Da terminale ho il messaggio di errore:
$ smplayer
(smplayer:4932): dbind-WARNING **: 08:12:11.601: Couldn’t connect to accessibility bus: Failed to connect to socket /var/lib/lxdm/.cache/at-spi/bus_0: Permesso negato
SMPlayer versione 25.6.0 (revision 10369) in esecuzione su Linux
Ho visto ora che se uso sudo smplayer si apre, ma non dovrebbe essere necessario usare sudo.
Comunque, non funziona. Mi da messagi di errore. Non va bene.
Fino ad oggi ha funzionato tranquillamente una scaletta di riproduzione in avvio automatico. Vorrei vederla tornare a funzionare.
Quando apro una sessione dal client funziona, solo che non esce suono dalle casse.
Mi sembra di capire che, in condizioni normali ovvero il mini-pc (definito VNCserver) quando parte non si ferma al login, ma, per tua scelta, entra automaticamente nel DE (lxde).
E’ vero?
Se Sì, questo potrebbe dare problemi.
P.S.: Come per l’altra discussione, audio inibito per l’utente connesso (2volte???)
No. Non è esatto. Il mini-pc impiegato come server, alla partenza si ferma al login, perchè ha 2 utenti.
L’utente che uso abitualmente ha la password in bianco, quindi clicko ed entro nel DE senza scrivere nessuna password.
P.S.:
Volendo vedere i permessi, ho guardato dove la guida dice che vengono salvate le password
“La password verrà memorizzata in ~/.vnc/passwdcon le autorizzazioni appropriate“
Ma non ho trovato nessun file “passwd”, anche se ho impostato “mostra nascosti”.
Dove sono?
P.S.: Se aggiungo un altro utente, per questo problema non può cambiare niente. Si presenta anche a client spento. Eventualmente, dovrei prima eliminare l’utente attuale di vnc.
Quindi ripristinare la situazione di partenza e riprovare con un’altra porta.
Come si fa?
Premessa: (sarebbe inutile farla, ma…quando ce vo’ ce vo’)
Ti ricordo che da me tutto “funza” e la mia configurazione è diversa dalla tua,
In ogni caso non sono un esperto di connessioni con VNC-server.
La modalità di utilizzo della tua macchina è solo tua ed a me interessa relativamente.
Credo che l’unico modo per procedere è quella per tentativi da eseguire esclusivamente sulla tua macchina.
Allora:
0) (Per adesso) Non devi ripristinare niente. La connessione va.
Il primo tentativo da fare (imho) è:
Entri al login con come tuo solito e sei dentro come “UTENTE-NORMALE” (prendila come definizione: non mi iteressa quale è il nome-utente.)
Dai in console sul server il seguente comando da “UTENTE-NORMALE” senza sudo:
$ vncserver
Posta qui l’output del comando.
Ciao.
Ecco il risultato:
$ vncserver
WARNING: vncserver has been replaced by a systemd unit and is now considered deprecated and removed in upstream.
Please read /usr/share/doc/tigervnc/HOWTO.md for more information.
You will require a password to access your desktops.
Password:
Vedo purtroppo che l’output è molto diverso dal mio, comunque facciamo un altro tentativo.
Prova a vedere se nella dir “~/.vnc” sul server c’è un file con estensione “.log”.
Se c’è posta qui il contenuto usando il comando: $cat nome-del-file.log
Ce ne sono 3 con date diverse ed altri 3 di backup.
Posto il più recente. E’ di questa mattina. Non ho ancora aperto una connessione dal client.
C’è scritto così:
$ cat fedora:1.log
Using desktop session LXDE
New ‘fedora:1 (utente)’ desktop is fedora:1
Starting desktop session LXDE
Xvnc TigerVNC 1.15.0 - built Jun 23 2025 00:00:00
Copyright (C) 1999-2025 TigerVNC team and many others (see README.rst)
See https://www.tigervnc.org for information on TigerVNC.
Underlying X server release 12101018
libEGL warning: failed to open /dev/dri/card1: Permission denied
libEGL warning: failed to open /dev/dri/card1: Permission denied
libEGL warning: failed to open /dev/dri/card1: Permission denied
Thu Oct 30 08:09:43 2025
vncext: VNC extension running!
vncext: Listening for VNC connections on all interface(s), port 5901
vncext: Created VNC server for screen 0
The XKEYBOARD keymap compiler (xkbcomp) reports:
Warning: Could not resolve keysym XF86RefreshRateToggle
Warning: Could not resolve keysym XF86Accessibility
Warning: Could not resolve keysym XF86DoNotDisturb
Errors from xkbcomp are not fatal to the X server
[mi] mieq: warning: overriding existing handler (nil) with 0x56539ab4f7e0 for event 2
[mi] mieq: warning: overriding existing handler (nil) with 0x56539ab4f7e0 for event 3
xinit: XFree86_VT property unexpectedly has 0 items instead of 1
** Message: 08:09:44.082: main.vala:113: Session is LXDE
** Message: 08:09:44.082: main.vala:114: DE is LXDE
** Message: 08:09:44.093: main.vala:145: log directory: /home/utente/.cache/lxsession/LXDE
** Message: 08:09:44.093: main.vala:146: log path: /home/utente/.cache/lxsession/LXDE/run.log
Ti posto il mio:
Xvnc TigerVNC 1.15.0 - built Jun 23 2025 00:00:00
Copyright (C) 1999-2025 TigerVNC team and many others (see README.rst)
See https://www.tigervnc.org for information on TigerVNC.
Underlying X server release 12101018
Wed Oct 29 11:09:37 2025
vncext: VNC extension running!
vncext: Listening for VNC connections on all interface(s), port 5901
vncext: Created VNC server for screen 0
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning: Could not resolve keysym XF86RefreshRateToggle
> Warning: Could not resolve keysym XF86Accessibility
> Warning: Could not resolve keysym XF86DoNotDisturb
Errors from xkbcomp are not fatal to the X server
[mi] mieq: warning: overriding existing handler (nil) with 0x55cd088407e0 for event 2
[mi] mieq: warning: overriding existing handler (nil) with 0x55cd088407e0 for event 3
Warning: VNC extension does not support -reset, terminating instead. Use -noreset to prevent termination.
Wed Oct 29 11:28:16 2025
ComparingUpdateTracker: 0 pixels in / 0 pixels out
ComparingUpdateTracker: (1:-nan ratio)
C’è qualcosa di diverso:
libEGL warning: failed to open /dev/dri/card1: Permission denied
libEGL warning: failed to open /dev/dri/card1: Permission denied
libEGL warning: failed to open /dev/dri/card1: Permission denied
Bisogna scoprire cosa sono questi warning con “Permission denied”
Vediamo se troviamo su internet qualche idea al riguardo.
Ciao.
Ho guardato /dev/dri/card1
Nessuno ha il permesso di eseguire quel file.
Ho provato a cambiare in “solo il proprietario ed il gruppo”, direttamente dal file manager, ma ho ottenuto il messaggio:
Errore nell’impostare i permessi: Operazione non permessa
EDIT:
Ora ho provato anche da secondo utente. Stesso risultato.
Per modificare i permessi su quel file, occorre farlo da terminale con sudo.
Ecco. Così ha funzionato:
sudo chmod ug=rwx card1
Funziona solo per la sessione corrente.
Se riavvio i permessi ritornano come prima.
Visto che il problema dell’audio si è dimostrato legato all’impiego della porta 5901, ora che ho passato la connessione dal client per il primo utente sulla porta 5902, ho eliminato da
/etc/tigervnc/vncserver.users la riga
:1=SECONDO UTENTE
ed ho eliminato la porta 5901 da firewall-cmd con il comando
sudo firewall-cmd --permanent --zone=public --remove-port=5901/tcp
Questa rimozione ha funzionato. E’ solo la rimozione dell’indirizzo IP sbagliato che non ha funzionato.
Il problema dei permessi, però non si è risolto.
Forse, dovrei fare anche l’operazione inversa di questa?
$ sudo systemctl enable vncserver@:1.service
$ sudo systemctl start vncserver@:1.service
Come devo scrivere esattamente per farla?
Oppure, non so proprio.
Se non ho capito male:
dal client (con vncviewer) se scrivi INDIRIZZO-IP:5901 non puoi più collegarti.
Quindi hai inibito la connessione del 1:PRIMO-UTENTE che non può più collegarsi al VNCserver.
La connessione invece funziona (con audio attivo) per il collegamento dal client (con vncviewer) se inserisci INDIRIZZO-IP:5902 e ti logghi come 2:SECONDO-UTENTE
Ma adesso non hai permessi?
Giusto?
Fammi capire quali sono i permessi inibiti nel caso 2) ???
La connessione che aveva funzionato (con audio attivo) era:
2:SECONDO-UTENTE su porta 5902
Visto così, ho pensato che era solo una questione di porte.
Allora ho prima cambiato:
1:Primo-Utente
2:Secondo-Utente
Con:
1:Secondo-Utente
2:Primo-Utente
Poi ho eliminato (troppo presto):
1:Secondo-Utente
Porta 5901
Ora Primo-Utente si collega tramite la porta 5902, ma non ottiene l’audio attivo.
Per quanto riguarda i permessi inibiti, il client non centra.
A client spento, usando il server normalmente, da solo.
Prima di iniziare questa esperienza della LAN tra i due mini-pc:
All’avvio della sessione lxde di Primo-Utente, partiva in automatico la mia colonna sonora della sessione, cioè una mia scaletta di musiche, in SMPlayer. Potevo tranquilamente usare dnfdragora per gli aggiornamenti e potevo lanciare qualsiasi programma dal menù di avvio.
Da quando è iniziata questa esperienza:
SMPlayer non parte più in automatico nè posso avviarlo da menù di avvio, dfndragora rifiuta di eseguire gli aggiornamenti ed un altro programma che ho visto che non posso avviare è GParted.
Mi sembra di capire che, giustamente, tu vorresti tornare alla condizione pre-esperienza VNCserver. Giusto?
Ferma ed inibisci tutti i sevizi VNCserver con i comandi:
$ sudo systemctl stop vncserver@:1.service
$ sudo systemctl stop vncserver@:2.service
$ sudo systemctl disable vncserver@:1.service
$ sudo systemctl disable vncserver@:2.service
e poi reboot con:
$ sudo shutdown -r now
Vedi se tutto torna alla pre-esperienza.
Fatto.
Tutto è tornato come prima.
Ora cosa si può tentare per vedere se posso avere la LAN senza quegli strani effetti collaterali?
Forse, ripristinare il solo vncserver@:2.service?
Potresti creare un nuovo utente in modo che abbia tutti i permessi (come l’utente root) seguendo fino in fondo questa guida
Poi ti logghi con questo utente e con riferimento alla solita guida per la generazione di un VNCserver, crei:
Così facendo dovresti trovarti in una situazione “pulita”, simile a quanto c’è dopo una formattazione.
A te la decisione.
Ciao.