• samba e vecchi client

    From Piviul@21:1/5 to All on Fri Jul 21 17:00:02 2023
    Ciao a tutti, samba è un po' che fa guerra ai vecchi client windows
    xp/2k e vedo che hanno anche le loro buone ragioni ma... non vorrei
    entrare nel merito della faccenda, vorrei solo pragmaticamente
    affrontare il problema.

    Come avrete capito sono in una situazione per cui in LAN ho ancora
    alcuni client xp. Ora un aggiornamento di windows ha fatto installare
    una pacth sul dc che taglia fuori tutti i client xp: non è più possibile
    ad un client xp di controllare le credenziali di un utente del dominio.
    Sono riuscito a contrattare che i client xp non accedano alla lan ma
    invece è necessario che dalla lan si possa accedere alle shares presenti
    sui client.

    Ho pensato ad una soluzione e prima di metterla in piedi volevo
    confrontarmi con voi, vedere se secondo voi può funzionare.

    Tolgo i client dal dominio e creo un utente locale in grado di leggere e scrivere sulle shares del client. Creo un server debian con tante shares
    quanti sono i pc e in ogni shares ci sono tante directory quante sono le
    shares messe a disposizione dal client rappresentato. Ora quindi mi
    rimarrebbe di trovare un modo per montare le shares dei clients sulle sottocartelle della shares del client. Quindi diciamo che il server
    debian avrebbe una struttura tipo:

    server debian
        clientxp1 (share del server debian)
            shares (del clientxp1)
            ...
        clientxp2 (share del server debian)
            shares (del clientxp2)
            ...

    A questo punto se il tutto funziona potrei addirittura isolare i clients
    xp in una sottorete accessibile soltanto dal server debian ma uello lo
    faccio dopo...

    Ora ho provato a metterla in pratica e ho già il primo problema: esiste
    un modo per montarle in automatico alla bisogna? Magari il client lo
    spengono poi lo riaccendono e bisogna che il mount lo si faccia quando
    serve. Un modo sarebbe quello di mettere in /etc/fstab le istruzioni per
    i mount e poi in preexec lanciare il comando mount ma già mi sono
    arenato: bisognerebbe aggiungere fra le opzioni vers=1.0 e se lo metto
    mi dice che c'è un errore di sintassi nel file /etc/fstab.

    in fstab ho aggiunto qualcosa tipo:

    mount.cifs //clientxp1/share1 -o credentials=/root/.admin_credentials,vers=1.0,uid=11202,gid=10513,forceuid,noperm
    /srv/samba/clientxp1/share1

    e al mount restituisce

    mount error(22): Invalid argument

    se tolgo il vers=1.0 invece non da più errore di sintassi ma il mount
    non riesce perché prova con protocolli non supportati dal clientxp1. Se
    invece quelle opzioni le uso con mount.cifs il tutto funziona.

    Forse ho messo troppa carne al fuoco...

    Ogni consiglio è ben accetto

    Piviul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Giuseppe Sacco@21:1/5 to All on Fri Jul 21 19:40:03 2023
    Ciao Piviul,

    Il giorno ven, 21/07/2023 alle 16.54 +0200, Piviul ha scritto:
    [...]
    in fstab ho aggiunto qualcosa tipo:

    mount.cifs //clientxp1/share1 -o credentials=/root/.admin_credentials,vers=1.0,uid=11202,gid=10513,forceuid,n operm
    /srv/samba/clientxp1/share1

    e al mount restituisce

    mount error(22): Invalid argument
    [...]

    Questa non è la sintassi esatta per /etc/fstab. Cos'hai scritto esattamente?

    Ciao,
    Giuseppe

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Piviul@21:1/5 to All on Mon Jul 24 07:40:01 2023
    This is a multi-part message in MIME format.
    Il 21/07/23 18:59, Giuseppe Sacco ha scritto:
    [...]

    Questa non è la sintassi esatta per /etc/fstab. Cos'hai scritto esattamente?
    ciao Giuseppe grazie, in fstab avevo scritto qualcosa tipo:

    //clientxp1/share1 /srv/samba/clientxp1/share1 cifs credentials=/root/.admin_credentials,vers='1.0',uid=11202,gid=10513,forceuid,noperm
    0 0

    se rimuovo vers='1.0' non da più l'errore di invalid argument ma non
    riesce a montarla. Se invece lancio il comando

    # mount.cifs //clientxp1/share1 -o credentials=/root/.admin_credentials,vers=1.0,uid=11202,gid=10513,forceuid,noperm
    /srv/samba/clientxp1/share1

    viene correttamente montata

    Piviul
    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    </head>
    <body>
    <div class="moz-cite-prefix">Il 21/07/23 18:59, Giuseppe Sacco ha
    scritto:<br>
    </div>
    <blockquote type="cite"
    cite="mid:9c0bc021df46839478dd158d067d2d5ae6da6481.camel@sguazz.it">
    <pre class="moz-quote-pre" wrap="">[...]

    Questa non è la sintassi esatta per /etc/fstab. Cos'hai scritto esattamente?</pre>
    </blockquote>
    ciao Giuseppe grazie, in fstab avevo scritto qualcosa tipo:<br>
    <br>
    <span style="font-family:monospace"><span
    style="color:#000000;background-color:#ffffff;">//clientxp1/share1
    /srv/samba/clientxp1/share1 cifs credentials=/root/.admin_credentials,vers='1.0',uid=11202,gid=10513,forceuid,noperm
    0 0<br>
    <br>
    se rimuovo vers='1.0' non da più l'errore di invalid argument ma
    non riesce a montarla. Se invece lancio il comando<br>
    </span></span><br>
    <span style="font-family:monospace"><span
    style="color:#000000;background-color:#ffffff;"># mount.cifs
    //clientxp1/share1 -o credentials=<i class="moz-txt-slash"><span
    class="moz-txt-tag">/</span>root<span class="moz-txt-tag">/</span></i>.admin_credentials,vers=1.0,uid=11202,gid=10513,forceuid,noperm
    /srv/samba/clientxp1/share1<br>
    <br>
    viene correttamente montata<br>
    <br>
    Piviul<br>
    </span></span>
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Alessandro Rubini@21:1/5 to All on Mon Jul 24 10:10:01 2023
    Se con '1.0' da` invalid argument e con 1.0 funziona, direi che il problema sono gli apici, anche se non uso samba.

    Aggiungere gli apici nel smbmount fatto a manina non avrebbe effetto, perche` l'apice viene usato dalla shell, che non interviene nell'uso da fstab.

    /alessandro

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Piviul@21:1/5 to Diego Zuccato on Mon Jul 24 10:50:01 2023
    On 7/23/23 20:55, Diego Zuccato wrote:
    Uhm... Non uso samba server da parecchio, ma non sarebbe più semplice "rigirare" il problema?
    Invece di usare le postazioni come server, sono loro a montare una
    share su un server (con Samba "adeguato"). Questo server a sua volta
    monta le share tramite NFS o altro. Un altro server con Samba
    aggiornato fornisce le share ai client nuovi dalla stessa "sorgente".
    In questo modo l'isolamento viene molto più naturale, e hai 3 VM
    semplici e solide invece di una sola delicatissima.

    si hai ragione ma il fatto è che i client xp sono collegati a strumenti
    che fanno le analisi e le salvano sul pc. Salvarli in remoto è
    sconsigliato dai produttori degli strumenti, preferirei accedere da
    remoto ai client xp piuttosto che far salvare loro su fs remoti.

    In fstab hai sbagliato completamente la sintassi, non devi indicare il comando di mount, solo i parametri:
    //clientxp1/share1 /srv/samba/clientxp1/share1 cifs credentials=/root/.admin_credentials,vers=1.0,uid=11202,gid=10513,forceuid,noperm


    hai ragione era un copia incolla sbagliato comunque Alessandro me lo ha risolto.

    Grazie ancora

    Piviul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Piviul@21:1/5 to All on Mon Jul 24 10:50:01 2023
    This is a multi-part message in MIME format.
    Il 23/07/23 20:55, Diego Zuccato ha scritto:
    Uhm... Non uso samba server da parecchio, ma non sarebbe più semplice "rigirare" il problema?
    Invece di usare le postazioni come server, sono loro a montare una
    share su un server (con Samba "adeguato"). Questo server a sua volta
    monta le share tramite NFS o altro. Un altro server con Samba
    aggiornato fornisce le share ai client nuovi dalla stessa "sorgente".
    In questo modo l'isolamento viene molto più naturale, e hai 3 VM
    semplici e solide invece di una sola delicatissima.
    I client xp sono client connessi a strumenti che salvano in locale i
    risultati delle analisi dello strumento. Poi da remoto un software
    dovrebbe leggere questi dati ed elaborarli facendo calcoli e verifiche.
    Salvare direttamente i dati in remoto la vedo dura la terrò come ipotesi
    di ultima spiaggia...

    In fstab hai sbagliato completamente la sintassi, non devi indicare il comando di mount, solo i parametri:
    //clientxp1/share1 /srv/samba/clientxp1/share1 cifs credentials=/root/.admin_credentials,vers=1.0,uid=11202,gid=10513,forceuid,noperm

    scusa hai ragione, ho trascritto male; questo è quello che ho scritto in
    fstab

    //clientxp1/share1 /srv/samba/clientxp1/share1 cifs credentials=/root/.admin_credentials,vers=1.0,uid=11202,gid=10513,forceuid,noperm
    0 0

    se rimuovo vers=1.0 non da più errore di invalid argument ma non si
    monta (di default parte da smb2+ in avanti)

    ma se lancio
    # mount.cifs //clientxp1/share1 -o credentials=/root/.admin_credentials,vers=1.0,uid=11202,gid=10513,forceuid,noperm
    /srv/samba/clientxp1/

    funziona

    altrimenti cerca la share "mount.cifs" da montare in
    "//clientxp1/share1" :)
    questa non l'ho capita...

    Mi sa anche che debba essere vers=1, non vers=1.0, ma a questo magari risponde qualcuno che conosce Samba meglio di me.
    questo non credo in man mount.cifs dice espressamente '1.0'

    Piviul
    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <title>Re: samba e vecchi client</title>
    </head>
    <body>
    <div class="moz-cite-prefix">Il 23/07/23 20:55, Diego Zuccato ha
    scritto:<br>
    </div>
    <blockquote type="cite"
    cite="mid:d684c0b9-cbe2-9683-7889-8de5d552dce2@unibo.it">Uhm...
    Non uso samba server da parecchio, ma non sarebbe più semplice
    "rigirare" il problema?
    <br>
    Invece di usare le postazioni come server, sono loro a montare una
    share su un server (con Samba "adeguato"). Questo server a sua
    volta monta le share tramite NFS o altro. Un altro server con
    Samba aggiornato fornisce le share ai client nuovi dalla stessa
    "sorgente".
    <br>
    In questo modo l'isolamento viene molto più naturale, e hai 3 VM
    semplici e solide invece di una sola delicatissima.
    <br>
    </blockquote>
    I client xp sono client connessi a strumenti che salvano in locale i
    risultati delle analisi dello strumento. Poi da remoto un software
    dovrebbe leggere questi dati ed elaborarli facendo calcoli e
    verifiche. Salvare direttamente i dati in remoto la vedo dura la
    terrò come ipotesi di ultima spiaggia...<br>
    <br>
    <blockquote type="cite"
    cite="mid:d684c0b9-cbe2-9683-7889-8de5d552dce2@unibo.it">In fstab
    hai sbagliato completamente la sintassi, non devi indicare il
    comando di mount, solo i parametri:
    <br>
    //clientxp1/share1 /srv/samba/clientxp1/share1 cifs credentials=/root/.admin_credentials,vers=1.0,uid=11202,gid=10513,forceuid,noperm
    <br>
    </blockquote>
    scusa hai ragione, ho trascritto male; questo è quello che ho
    scritto in fstab<br>
    <br>
    <span style="font-family:monospace"><span
    style="color:#000000;background-color:#ffffff;">//clientxp1/share1
    /srv/samba/clientxp1/share1 cifs credentials=/root/.admin_credentials,vers=1.0,uid=11202,gid=10513,forceuid,noperm
    0 0</span><br>
    <br>
    se rimuovo vers=1.0 non da più errore di invalid argument ma non
    si monta (di default parte da smb2+ in avanti)<br>
    <br>
    ma se lancio <br>
    # </span><span style="font-family:monospace"><span
    style="color:#000000;background-color:#ffffff;">mount.cifs
    //clientxp1/share1 -o credentials=/root/.admin_credentials,vers=1.0,uid=11202,gid=10513,forceuid,noperm
    </span></span><span style="font-family:monospace"><span
    style="color:#000000;background-color:#ffffff;"><span
    style="font-family:monospace"><span
    style="color:#000000;background-color:#ffffff;">/srv/samba/clientxp1/
    <br>
    <br>
    funziona<br>
    <br>
    </span></span></span></span><span
    style="font-family:monospace"></span>
    <blockquote type="cite"
    cite="mid:d684c0b9-cbe2-9683-7889-8de5d552dce2@unibo.it">
    altrimenti cerca la share "mount.cifs" da montare in
    "//clientxp1/share1" :)
    <br>
    </blockquote>
    questa non l'ho capita...<br>
    <br>
    <blockquote type="cite"
    cite="mid:d684c0b9-cbe2-9683-7889-8de5d552dce2@unibo.it">
    Mi sa anche che debba essere vers=1, non vers=1.0, ma a questo
    magari risponde qualcuno che conosce Samba meglio di me.
    <br>
    </blockquote>
    questo non credo in man mount.cifs dice espressamente '1.0'<br>
    <br>
    Piviul<br>
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Piviul@21:1/5 to Alessandro Rubini on Mon Jul 24 10:30:01 2023
    On 7/24/23 10:07, Alessandro Rubini wrote:
    Se con '1.0' da` invalid argument e con 1.0 funziona, direi che il problema sono gli apici, anche se non uso samba.

    bingo!

    Grazie Alessandro, il problema erano gli apici...

    Grazie

    Piviul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marco Gaiarin@21:1/5 to All on Mon Jul 24 15:50:01 2023
    Mandi! Piviul
    In chel di` si favelave...

    Come avrete capito sono in una situazione per cui in LAN ho ancora
    alcuni client xp. Ora un aggiornamento di windows ha fatto installare
    una pacth sul dc che taglia fuori tutti i client xp: non pi possibile
    ad un client xp di controllare le credenziali di un utente del dominio.

    Scusa: quindi hai un dominio AD con uno (o pi) domain controller windows?


    Ho pensato ad una soluzione e prima di metterla in piedi volevo
    confrontarmi con voi, vedere se secondo voi pu funzionare.

    Fatto salvo che sembra, da rumors in lista samba, che Microsoft si sia
    accorta di aver fattola cavolata eche arriver patch a fissare la cosa,
    ma... non puoi semplicemente togliere dal dominio la macchina e farla
    accedere agli share usando user e pass di dominio?

    AFAIK precluso il 'join' al dominio, ma non l'accesso agli share... in
    caso prova anche ad accedere in nuemrico (\\10.X.Y.Z\Share), solitamente implica la disabilitazione di Kerberos.

    --
    L'unico metodo naturale per arrestare la caduta dei capelli
    e` il pavimento. (Marco d'Itri)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Piviul@21:1/5 to Marco Gaiarin on Thu Jul 27 08:30:01 2023
    On 7/24/23 14:33, Marco Gaiarin wrote:
    Mandi! Piviul
    In chel di` si favelave...
    Come avrete capito sono in una situazione per cui in LAN ho ancora
    alcuni client xp. Ora un aggiornamento di windows ha fatto installare
    una pacth sul dc che taglia fuori tutti i client xp: non è più possibile >> ad un client xp di controllare le credenziali di un utente del dominio.
    Scusa: quindi hai un dominio AD con uno (o più) domain controller windows?

    no, ho un dominio ad gestito da samba.

    Ho pensato ad una soluzione e prima di metterla in piedi volevo
    confrontarmi con voi, vedere se secondo voi può funzionare.
    Fatto salvo che sembra, da rumors in lista samba, che Microsoft si sia accorta di aver fattola cavolata eche arriverà patch a fissare la cosa, ma... non puoi semplicemente togliere dal dominio la macchina e farla accedere agli share usando user e pass di dominio?

    AFAIK è precluso il 'join' al dominio, ma non l'accesso agli share... in caso prova anche ad accedere in nuemrico (\\10.X.Y.Z\Share), solitamente implica la disabilitazione di Kerberos.

    si infatti con gli ip funziona ancora, non da tutti i client però... è comunque una questione a cui devo mettere mano al più presto.

    Ho messo su l'accrocchio, funzionerebbe anche bene se non fosse per quel maledetto oplock... Ricapitolando ho messo in piedi un server
    "xpclients" che ha una share per ogni client e con in preexec uno script
    che va a leggere le shares del client xp rappresentato dalla share e le
    monta in SMB1 nella stessa cartella della share. In altre parole ho un
    client windows che almeno in SMB2 si connette a una share di xpclients
    il quale in automatico monta in SMB1 le shares presenti sulla directory
    stessa (se volete dettagli ve li mando). Il client riesce a sfogliare le cartelle, sembra andare tutto bene tranne che scrivendo nella share
    l'explorer di windows si incasina e bisogna riavviare il pc. Lato server (xpclients) nei logs trovo dei messaggi tipo "close_remove_share_mode:
    Could not get share mode lock for file ...".

    Ad esempio se aggiungo un file di testo nei logs trovo:

    [2023/07/27 07:51:00.516465,  0] ../../source3/smbd/close.c:312(close_remove_share_mode)
      close_remove_share_mode: Could not get share mode lock for file csa/ARCHIVIO_EXCEL/E00091/Nuovo documento di testo.txt
    [2023/07/27 07:51:00.854188,  0] ../../source3/smbd/close.c:312(close_remove_share_mode)
      close_remove_share_mode: Could not get share mode lock for file csa/ARCHIVIO_EXCEL/E00091/Nuovo documento di testo (2).txt
    [2023/07/27 07:51:00.861062,  0] ../../source3/smbd/close.c:312(close_remove_share_mode)
      close_remove_share_mode: Could not get share mode lock for file csa/ARCHIVIO_EXCEL/E00091/Nuovo documento di testo.txt
    [2023/07/27 07:51:01.226151,  0] ../../source3/smbd/close.c:312(close_remove_share_mode)
      close_remove_share_mode: Could not get share mode lock for file csa/ARCHIVIO_EXCEL/E00091/Nuovo documento di testo (3).txt
    [2023/07/27 07:51:01.233055,  0] ../../source3/smbd/close.c:312(close_remove_share_mode)
      close_remove_share_mode: Could not get share mode lock for file csa/ARCHIVIO_EXCEL/E00091/Nuovo documento di testo.txt
    [2023/07/27 07:51:01.239420,  0] ../../source3/smbd/close.c:312(close_remove_share_mode)
      close_remove_share_mode: Could not get share mode lock for file csa/ARCHIVIO_EXCEL/E00091/Nuovo documento di testo (2).txt
    [2023/07/27 07:51:01.554350,  0] ../../source3/smbd/close.c:312(close_remove_share_mode)
      close_remove_share_mode: Could not get share mode lock for file csa/ARCHIVIO_EXCEL/E00091/Nuovo documento di testo (4).txt
    [2023/07/27 07:51:21.547357,  0] ../../source3/smbd/close.c:312(close_remove_share_mode)
      close_remove_share_mode: Could not get share mode lock for file csa/ARCHIVIO_EXCEL/E00091/Nuovo documento di testo (4).txt

    A questo punto mi chiedo:

    Quale protocollo di condivisione files alternativo a samba potrei
    trovare tra client linux e windows xp come server?

    Altrimenti qualcuno sa come disabilitare l'oplock sui client windows ma
    solo quando si connette a xpclients?

    Grazie!

    Piviul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Piviul@21:1/5 to Diego Zuccato on Thu Jul 27 10:10:01 2023
    On 7/27/23 08:33, Diego Zuccato wrote:
    A naso devi separare le due istanze di Samba con un layer "neutrale",
    che può essere un NFS o anche solo rsync (o unison, se vuoi gestire
    meglio la sincronizzazione bidirezionale). Non credo si riesca a
    gestire con una sola macchina.

    in che senso? Mettiamo di creare 2 server, server1 e server2. server1
    monta le shares di server2 che monta le shares della macchina xp? Quindi
    il client windows con server1 comunicano utilizzando una versione
    maggiore di SMB1 mentre invece server1 e server2 che versione usano?
    Mentre do per scontato che server2 e xp parlino SMB1. E perché dovrebbe risolvere la cosa?

    Piviul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Piviul@21:1/5 to Piviul on Thu Jul 27 11:20:02 2023
    On 7/27/23 08:27, Piviul wrote:
    [...]
    Altrimenti qualcuno sa come disabilitare l'oplock sui client windows
    ma solo quando si connette a xpclients?

    ho provato ma continua a darmi sempre lo stesso errore...

    Dal client windows ho provato da powershell con diritti amministrativi a lanciare

     set-smbclientconfiguration -useOpportunisticLocking 0 -OplocksDisabled 1

    ma non è cambiato nulla..

    Ho provato anche ad inserire in smb.conf nella configurazione della share

       oplocks = False
       level2 oplocks = False

    ma non è cambiato nulla...

    Ho provato ad aggiungere in [global] di smb.conf

       reset on zero vc = yes

    ma non è cambiato nulla... a questo punto non so cosa pensare :(

    Piviul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Giuseppe Sacco@21:1/5 to All on Thu Jul 27 12:40:01 2023
    Ciao,

    Il giorno gio, 27/07/2023 alle 12.18 +0200, Piviul ha scritto:
    purtroppo non è così semplice, come dicevo i client xp devono salvare i dati in locale, questo è un prerequisito del software utilizzato;
    inoltre mi server la propagazione immediata, niente rsync di mezzo.
    Quindi dovrà essere server2 a montare una share di xp, utilizzando SMB1? Quindi poi server2 la esporta a server1 in NFS? Questo secondo te
    dovrebbe risolvere il problema?

    Mi intrometto perché ho fatto una cosa simile di recente: NFS non è in
    grado di esportare un file system che non sia locale proprio a causa degli oplock. C'è però una versione di NFS non presente in Debian, che non
    gestisce gli oplock e che permette di esportare anche un file system che
    non sia locale, ad esempio uno montato tramite cifs.

    Dovrebbe essere uNFSd https://github.com/unfs3/unfs3

    Ciao,
    Giuseppe

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Piviul@21:1/5 to Giuseppe Sacco on Thu Jul 27 13:00:01 2023
    On 7/27/23 12:32, Giuseppe Sacco wrote:
    Mi intrometto perché ho fatto una cosa simile di recente:

    non mi sembra il caso di giustificarsi, anzi a priori ti ringrazio! ;)


    NFS non è in
    grado di esportare un file system che non sia locale proprio a causa degli oplock. C'è però una versione di NFS non presente in Debian, che non gestisce gli oplock e che permette di esportare anche un file system che
    non sia locale, ad esempio uno montato tramite cifs.

    quindi anche tu mi stai dicendo di creare 2 server, il primo offre una condivisione smb (> smb1) ai client windows della lan, il secondo invece
    monta in smb1 le shares xp e poi le esporta al primo server, in nfs
    utilizzando unfs3. Ho capito bene?

    Ma non era più intelligente mettere un'opzione di non usare gli oplock invece  di creare ex novo un nuovo nfsd?

    Piviul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Piviul@21:1/5 to Diego Zuccato on Thu Jul 27 12:20:02 2023
    On 7/27/23 10:36, Diego Zuccato wrote:
    No, il passaggio tra i server non deve avvenire tramite Samba.
    server2 ha Samba vecchio e espone una share NFS. All'interno
    dell'albero esportato monta le share XP.
    server1 monta la share di server2 e la riesporta con Samba nuovo.

    Rimane una soluzione abbastanza fragile (p.e. ogni volta che monti o
    smonti una share XP potresti dover smontare e rimontare la share NFS su s

    purtroppo non è così semplice, come dicevo i client xp devono salvare i
    dati in locale, questo è un prerequisito del software utilizzato;
    inoltre mi server la propagazione immediata, niente rsync di mezzo.
    Quindi dovrà essere server2 a montare una share di xp, utilizzando SMB1? Quindi poi server2 la esporta a server1 in NFS? Questo secondo te
    dovrebbe risolvere il problema?

    Piviul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Giuseppe Sacco@21:1/5 to All on Thu Jul 27 14:50:01 2023
    Il giorno gio, 27/07/2023 alle 12.57 +0200, Piviul ha scritto:
    [...]
    quindi anche tu mi stai dicendo di creare 2 server, il primo offre una condivisione smb (> smb1) ai client windows della lan, il secondo invece monta in smb1 le shares xp e poi le esporta al primo server, in nfs utilizzando unfs3. Ho capito bene?



    Ma non era più intelligente mettere un'opzione di non usare gli oplock invece  di creare ex novo un nuovo nfsd?

    Credo siano progetti diversi. uNFSd non è nato per non gestire gli oplock,
    ma per operare nello spazio utente anziché nel kernel. Magari un giorno aggiungeranno gli oplock 🙂

    Ciao,
    Giuseppe

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marco Gaiarin@21:1/5 to All on Tue Aug 1 17:50:01 2023
    Mandi! Piviul
    In chel di` si favelave...

    Scusa: quindi hai un dominio AD con uno (o pi) domain controller windows?
    no, ho un dominio ad gestito da samba.

    Ma allora, scusa, non ti basta abbassare il 'min protocol'?!

    client ipc min protocol = NT1

    Lato Samba non cambiato nulla, non dovrebbero essere sorte incompatibilit con le ultime release, fatto salvo il 'min protocol' che stato innalzato a 'SMB2'.

    Lato windows con il patch tuesday di luglio M$ ha inserito una
    incompatibilit e ha 'scazzato' i dominii NT (e non solo quello, ma principalmente quello).


    Insomma, non capisco perch XP non ti si colleghi al dominio, dovrebbe farlo senza problemi...

    --
    Il computer come la morosa:
    meno ci mettono mano gli altri e meglio ! ;-)
    (Enrico)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Piviul@21:1/5 to Marco Gaiarin on Wed Aug 2 14:40:04 2023
    On 8/1/23 15:09, Marco Gaiarin wrote:
    Mandi! Piviul
    In chel di` si favelave...

    Scusa: quindi hai un dominio AD con uno (o più) domain controller windows? >> no, ho un dominio ad gestito da samba.
    Ma allora, scusa, non ti basta abbassare il 'min protocol'?!

    client ipc min protocol = NT1

    dove? Parliamo di macchine xp che non dialogano con il dominio, scusa,
    sarò zuccone ma non capisco... dovrei metterlo nell'smb.conf del DC?


    Lato Samba non è cambiato nulla, non dovrebbero essere sorte incompatibilità
    con le ultime release, fatto salvo il 'min protocol' che è stato innalzato a 'SMB2'.

    Lato windows con il patch tuesday di luglio M$ ha inserito una incompatibilità e ha 'scazzato' i dominii NT (e non solo quello, ma principalmente quello).


    Insomma, non capisco perchè XP non ti si colleghi al dominio, dovrebbe farlo senza problemi...

    forse per il "non solo quello" che citi? Non so, io ti posso dire che
    qui è un casino. Sto facendo delle prove con un client xp fuori dal
    dominio, ho fatto un utente locale, ho condiviso la cartella con i
    permessi in scrittura a quell'utente; ho aggiunto alla cartella i
    permessi in scrittura per quell'utente. Se cerco di collegarmi alla
    share mi da accesso negato a meno che non entri come admin del computer
    locale.

    Non so cosa pensare

    Piviul :(

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marco Gaiarin@21:1/5 to All on Sun Aug 6 21:50:02 2023
    Mandi! Piviul
    In chel di` si favelave...

    client ipc min protocol = NT1
    dove? Parliamo di macchine xp che non dialogano con il dominio, scusa,
    sar zuccone ma non capisco... dovrei metterlo nell'smb.conf del DC?

    Dappertutto. Se hai macchine che non sanno parlare SMB2 e successivi, non
    hai alternativa nelle recenti Samba ad abbassare il 'min protocol'.


    forse per il "non solo quello" che citi?

    Ma quella una modifica client side fatta su Win10 e Win11, la patch non sicuramente finita in Win7 e tanto meno in XP.

    --
    La giustizia militare sta alla giustiza come la musica militare sta alla
    musica. (George Clemenceau)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Piviul@21:1/5 to All on Tue Aug 29 08:40:01 2023
    Alla fine mi sono arreso, ai client xp si accede con utente locale, non
    li ho rimossi dal dominio e per potersi connettere come utente locale mi
    sono inventato un mezzo accrocchio...

    Grazie a tutti

    Piviul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Paolo_Red=c3=a6lli?=@21:1/5 to All on Tue Aug 29 14:50:01 2023
    Mi permetto una soluzione ardita: taglia la testa al toro e prova https://github.com/winfsp/sshfs-win 😁

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)