Machine R = Routeur firewall avec serveur VPN OpenSwan sur LAN
Serveur A = Client VPN via OpenSwan (a l'exterieur du LAN)
Serveur B = Serveur de fichier (NFS et Samba) du LAN
Depuis le serveur B, si je fait un
# mount -t nfs ip_serveurA:/home /home/serveurA
tout ce passe très bien
Sur le serveur B, je peut lire et ecrire sur /home/serveurA (donc sur
serveur A en fin de compte)
Mon serveur B exporte son /home pour le LAN
Si depuis une machine du LAN je fais
# mount -t nfs ip_serveurB:/home /mnt/serveurB
Je peut lire (et ecrire selon les droits dudit repertoire) tous les
fichiers. Mais si j'essaye de lire /mnt/serveurB/serveurA cela m'est
impossible. Aucun message d'erreur, mais répertoire vide.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Olivier Thauvin
Alain JUPIN wrote:
Bonjour,
Voici la configuration
Machine R = Routeur firewall avec serveur VPN OpenSwan sur LAN
Serveur A = Client VPN via OpenSwan (a l'exterieur du LAN) Serveur B = Serveur de fichier (NFS et Samba) du LAN
Depuis le serveur B, si je fait un # mount -t nfs ip_serveurA:/home /home/serveurA tout ce passe très bien
Sur le serveur B, je peut lire et ecrire sur /home/serveurA (donc sur serveur A en fin de compte)
Mon serveur B exporte son /home pour le LAN
Si depuis une machine du LAN je fais # mount -t nfs ip_serveurB:/home /mnt/serveurB
Je peut lire (et ecrire selon les droits dudit repertoire) tous les fichiers. Mais si j'essaye de lire /mnt/serveurB/serveurA cela m'est impossible. Aucun message d'erreur, mais répertoire vide.
Une idée sur l'origine du problème ?
Oui, nfs ne traverse pas les filesystem, et ne le fera jamais. En clair sur un serveur nfs posons: /dev/hda5 monté sur /export /dev/hda6 monté sur /export/2nd_disque
sur le client je monte serveur:/export dans /export, /export/2nd_disque restera désespérément vide. Solution: monter sur le client serveur:/export/2nd_disque dans /export/2nd_disque.
Explication: nfs identifie les fichiers par leur n° d'inode. Un numéro d'inode est unique au sein du filesystem. Si nfs traversais les filesystem, il ne saurait plus identifier le filesystem d'origine sur le serveur. Une solution serait de regarder sur les filesystems un par un lequel a un fichier avec ce n° d'inode, c'est vrai, mais dans ce cas, que faire si jamais plusieurs filesystems ont l'inode avec le n° demandé. Bref sans parler de la charge pour explorer chaque fs un par un, le risque d'effet de bord et donc de corruption est trop grand même si très faible (la tolérance au effets de bords dans un tel cas est bien sûr nulle).
Alain JUPIN wrote:
Bonjour,
Voici la configuration
Machine R = Routeur firewall avec serveur VPN OpenSwan sur LAN
Serveur A = Client VPN via OpenSwan (a l'exterieur du LAN)
Serveur B = Serveur de fichier (NFS et Samba) du LAN
Depuis le serveur B, si je fait un
# mount -t nfs ip_serveurA:/home /home/serveurA
tout ce passe très bien
Sur le serveur B, je peut lire et ecrire sur /home/serveurA (donc sur
serveur A en fin de compte)
Mon serveur B exporte son /home pour le LAN
Si depuis une machine du LAN je fais
# mount -t nfs ip_serveurB:/home /mnt/serveurB
Je peut lire (et ecrire selon les droits dudit repertoire) tous les
fichiers. Mais si j'essaye de lire /mnt/serveurB/serveurA cela m'est
impossible. Aucun message d'erreur, mais répertoire vide.
Une idée sur l'origine du problème ?
Oui, nfs ne traverse pas les filesystem, et ne le fera jamais.
En clair sur un serveur nfs posons:
/dev/hda5 monté sur /export
/dev/hda6 monté sur /export/2nd_disque
sur le client je monte serveur:/export dans /export, /export/2nd_disque
restera désespérément vide. Solution: monter sur le client
serveur:/export/2nd_disque dans /export/2nd_disque.
Explication: nfs identifie les fichiers par leur n° d'inode. Un numéro
d'inode est unique au sein du filesystem. Si nfs traversais les filesystem,
il ne saurait plus identifier le filesystem d'origine sur le serveur. Une
solution serait de regarder sur les filesystems un par un lequel a un
fichier avec ce n° d'inode, c'est vrai, mais dans ce cas, que faire si
jamais plusieurs filesystems ont l'inode avec le n° demandé. Bref sans
parler de la charge pour explorer chaque fs un par un, le risque d'effet de
bord et donc de corruption est trop grand même si très faible (la tolérance
au effets de bords dans un tel cas est bien sûr nulle).
Machine R = Routeur firewall avec serveur VPN OpenSwan sur LAN
Serveur A = Client VPN via OpenSwan (a l'exterieur du LAN) Serveur B = Serveur de fichier (NFS et Samba) du LAN
Depuis le serveur B, si je fait un # mount -t nfs ip_serveurA:/home /home/serveurA tout ce passe très bien
Sur le serveur B, je peut lire et ecrire sur /home/serveurA (donc sur serveur A en fin de compte)
Mon serveur B exporte son /home pour le LAN
Si depuis une machine du LAN je fais # mount -t nfs ip_serveurB:/home /mnt/serveurB
Je peut lire (et ecrire selon les droits dudit repertoire) tous les fichiers. Mais si j'essaye de lire /mnt/serveurB/serveurA cela m'est impossible. Aucun message d'erreur, mais répertoire vide.
Une idée sur l'origine du problème ?
Oui, nfs ne traverse pas les filesystem, et ne le fera jamais. En clair sur un serveur nfs posons: /dev/hda5 monté sur /export /dev/hda6 monté sur /export/2nd_disque
sur le client je monte serveur:/export dans /export, /export/2nd_disque restera désespérément vide. Solution: monter sur le client serveur:/export/2nd_disque dans /export/2nd_disque.
Explication: nfs identifie les fichiers par leur n° d'inode. Un numéro d'inode est unique au sein du filesystem. Si nfs traversais les filesystem, il ne saurait plus identifier le filesystem d'origine sur le serveur. Une solution serait de regarder sur les filesystems un par un lequel a un fichier avec ce n° d'inode, c'est vrai, mais dans ce cas, que faire si jamais plusieurs filesystems ont l'inode avec le n° demandé. Bref sans parler de la charge pour explorer chaque fs un par un, le risque d'effet de bord et donc de corruption est trop grand même si très faible (la tolérance au effets de bords dans un tel cas est bien sûr nulle).
