nfs server

[vmlinuz]

in rete ho trovato anche questo ma differisce un po' dal mio rpcinfo -p

[vmlinuz]

ciao, sempre io...
credo sempre più fermamente che sia il firewall che da noia all'rpc. ho aggiunto quelle righe però continua a non funzionare (il mio rpcinfo mi indicava quelle porte)

2 domande:
come mai il firewall da noia nonostante abbia messo
/sbin/iptables -A INPUT -j ACCEPT -i eth0 -s 192.168.1.0/24
che a regola accetta tutto dalla lan

per quanto riguarda poi la configurazione del client dicono solamente di fare il mount (o tramite fstab o a mano) e non ho mai trovato implicazioni dell'rpc (se ne parla sempre solo per il server)... ma l'rpc del client deve funzionare per comunicare col server no?

[andy caps]

dai un iptables -F e riconfigura la rete poi prova
dovrebbe azzerare tutte le regole del firewall

[vmlinuz]

si, ho fatto proprio così (o meglio ho riavviato senza far partire il firewall) e, in questo modo, 'rpcinfo -p' su debian funziona. come però faccio 'rpcinfo -p slack' mi dice che praticamente l'rpc sul client (la slack appunto) non è raggiungibile...
da qui il dubbio: siamo sicuri che non devo configurare l'rpc sul client? riguardo ad esso le guide che ho trovato fanno riferimento solo al mount... (l'rpc viene configurato solo dal lato server)

forse mi ero spiegato male...

[vmlinuz]

guarda che succede senza firewall:

da slack:

slack://. rpcinfo -p debian
   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100003    2   udp   2049  nfs
    100021    1   udp  32768  nlockmgr
    100021    3   udp  32768  nlockmgr
    100021    4   udp  32768  nlockmgr
    100005    1   udp  32770  mountd
    100005    1   tcp  32768  mountd
    100005    2   udp  32770  mountd
    100005    2   tcp  32768  mountd
    100005    3   udp  32770  mountd
    100005    3   tcp  32768  mountd
    100024    1   udp  32771  status
    100024    1   tcp  32771  status

slack://. rpcinfo -p
   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp   1000  status
    100024    1   tcp   1003  status

slack://. mount debian:/lan /lan
mount: debian:/lan failed, reason given by server:
Permission denied:

mentre da debian

debian://. mount /lan slack:/lan
mount: mount point slack:/lan does not exist

debian://. mount /lan 192.168.1.2:/lan
mount: mount point 192.168.1.2:/lan does not exist

[andy caps]

mount /lan 192.168.1.2:/lan questa riga è sbagliata

mount 192.168.1.2:/lan /lan

metti gli hostname poi

ricontrolla exports di tutti e due i computer

[vmlinuz]

mount /lan 192.168.1.2:/lan

è sbagliata? a regola, da debian...

mount /lan slack:/lan

avevo provato anche con l'hostname ma il risultato è uguale
un paio di risposte sopra avevo postato anche gli hosts.allow e deny



più che altro non capisco qusto output:

slack://. mount debian:/lan /lan
mount: debian:/lan failed, reason given by server: Permission denied:

i permessi non sono gestiti solamente dai file hosts.allow e deny ed exports? o mi devo preoccupare anche di altre cose tipo i permessi delle cartelle coinvolte...

[andy caps]

si ma da root non dovrebbe dare problemi di permessi

dal pc in cui vuoi prelevare i dati per esportarlo nell'altro commenta totalmente host-deny e host-allow
poi restarta portmap e ntfs magari installaci user-server

[vmlinuz]

tadadadan!!!
ce l'ho fatta!!!

allora:
prima di tutto ho rimesso nfs-user-server come mi avevi consigliato.
poi: sul server ho avviato il portmap, l'rpc.nfsd e l'rpc.mountd; non so come parta il portmap (dopo tutti i tentativi che ho fatto ho perso la sequenza delle operazioni ) ma gli altri due vengono avviati da /etc/init.d/nfs-user-server.
sul client ho l'rpc.portmap, il lockd e un certo rpciod (mentre il portmap ha il suo rc.portmap, gli altri due penso vengano avviati dai due pacchetti nfs-utils).
infine i file /etc/exports, /etc/hosts.allow e /etc/hosts.deny sono quelli postati l'ultima volta (probabilmente potrei anche utilizzare più restrizioni...)
un ultimo dubbio: l'rpcinfo sul server continua a non funzionare; risponde solo se eseguito dal client...

ringrazio ovviamente tutti in questo forum, ma un grazie particolare va naturalmente ad andy caps che, come dimostra questo post, ha una pazienza veramente sovraumana

[andy caps]

http://info.astrian.net/doc/HOWTO/it...OWTO.html#toc3

guarda anche qui per l'rpc
qualcuno consiglia al limite di rinominare hosts-deny e hosts-allow