Problème copie de fichier

Bonjour,

Voilà je suis débutant et j'ai un problème sur des script KSH qui doivent copier des fichiers sur un NAS pour mon boulot sur solaris...

Nous utilisons des versions de cp/mv issues de GNU (l'install a été faite comme çà, je ne sais pas pourquoi):

Code:

---

1 2 3 4

>ll /opt/gnu/bin/sparcv9/cp -rwxrwxr-x 1 batch batch 251320 Jul 7 2011 /opt/gnu/bin/sparcv9/cp >ll /opt/gnu/bin/sparcv9/mv -rwxrwxr-x 1 batch batch 267264 Jul 7 2011 /opt/gnu/bin/sparcv9/mv

---

Le NAS a été configuré pour être accessible en écriture/lecture pour tout le monde de la façon suivante:

Code:

---

1 2	d--------- 4 root root 4096 Mar 9 18:16 in d--------- 4 root root 4096 Mar 9 18:16 out

---

Quand j'essaie de copier le fichier dans le répertoire "in", il me met "permission denied"

Un des administrateur système nous indique d'utiliser "/bin/cp" et "/bin/mv" à la place:

Code:

---

1 2 3 4

>ll /bin/cp -r-xr-xr-x 3 root bin 27340 Jul 7 2009 /bin/cp >ll /bin/mv -r-xr-xr-x 3 root bin 27340 Jul 7 2009 /bin/mv

---

Savez-vous pourquoi cela fonctionne dans un cas et pas dans l'autre?

Vous remerciant par avance

Cordialement,

VF

Citation:

---

Envoyé par vfanelia

Le NAS a été configuré pour être accessible en écriture/lecture pour tout le monde de la façon suivante:
d--------- 4 root root 4096 Mar 9 18:16 in
d--------- 4 root root 4096 Mar 9 18:16 out

---

Les deux répertoires ne sont pas en écriture/lecture pour tout le monde mais exactement le contraire, à moins que le "ls" de GNU ait lui aussi des problèmes.

Merci Jlliagre pour la réponse...

Je m’étais également fait la réflexion car voir les permissions définies ainsi (d---------) et en plus en root:root, cela me paraissait bizarre mais comme il s'agit d'un NAS, peut-être est-ce normal

Par contre ça n'explique toujours pas pourquoi le "/bin/cp" fonctionne et pas le "/opt/gnu/bin/sparcv9/cp"... à moins que cela soit du au user:group défini en root:bin et pas l'autre ?

Cordialement

VF

PS: Merci paissad pour la correction de la mise en page, c'est effectivement plus lisible :ccool:

Quel "ls" utilises-tu, le standard ou celui de GNU ?
Quel NAS ?
Ces permissions n'ont rien de normal.
Le user/group à root/bin ne devrait avoir aucun impact.

ça pue le NAS qui n'est pas formaté par Unix mais par exemple en VFAT ou autre et ducoup les droits Unix ne sont pas du tout gérés par le NAS d'où l'aberation

Code:

---

d---------

---

le mieux à faire est donc de formater Unix le NAS après avoir fait une sauvegarde de toute les données bien sur... et de les restaurer.

J'ai eu un cas qui ressemblai .... Un NAS qui affichait les droits unix mais ne les appliquait pas... pour cette raison. Et lorsque j'ai voulu modifier les droits racine du NAS j'ai eu des sous-volumes avec

Code:

---

d---------

---

je suppose donc que tu es dans le même genre de cas.

Citation:

---

Envoyé par frp31

le mieux à faire est donc de formater Unix le NAS après avoir fait une sauvegarde de toute les données bien sur... et de les restaurer.

---

Ce n'est pas quelque chose que je conseillerais. Un NAS doit présenter des droits corrects. S'il ne le fait pas, il faut corriger sa configuration, voire son code mais de là à conseiller l'utilisation d'un autre système de fichier (si c'est ce que tu appelle "formater Unix"), il y a un pas que je me garderais de franchir. Il y a probablement d'autres utilisateurs de ce NAS qui utilisent autre chose qu'Unix et risqueraient de pâtir de ce changement.

Mais les autres utilisateurs ont ils seulement le droit d'exister ? on ne se pose jamais la question ... :mouarf::mouarf::mouarf: Tuez les tous :ccool:

Bonjour à tous

Merci pour vos retour sur ce problème...

Effectivement, ce NAS n'est pas que utilisé par notre serveur Solaris mais également par d'autres systèmes notamment sous Windows...

La commande "ls" Solaris (/bin/ls) donne exactement le même affichage (d---------)

Comme cela est problématique et que nous ne pouvons pas modifié tous les script utilisant les commandes cp/mv, nous avons temporairement modifié ces commandes dans "/opt/gnu/bin/sparcv9" en les remplaçant par des liens vers "/bin":

Citation:

---

/opt/gnu/bin/sparcv9>ll cp mv
lrwxrwxrwx 1 batch batch 7 May 14 11:26 cp -> /bin/cp
lrwxrwxrwx 1 batch batch 7 May 14 11:44 mv -> /bin/mv

---

Cela semble fonctionner maintenant... mais je n'ai toujours pas compris pourquoi le "/bin/cp" fonctionne et pas l'autre même si les droits sont incorrect sur le NAS

Cordialement

VF

/opt/gnu/bin ne fait pas partie de Solaris. Tout binaire qui s'y trouve n'est pas supporté. Qu'il ne fonctionne pas comme attendu n'est donc pas forcément une surprise.

Il est possible d'analyser comment fonctionne le cp de gnu pour voir pourquoi il sort en erreur. J'imagine qu'il vérifie d'abord si la commande peut réussir en observant les droits du répertoire et constatant que ces derniers sont insuffisants, il sort en erreur. Le cp de Solaris doit lui ne pas exiger ce préalable et copie le fichier sans se poser de questions.

Tu n'a pas dit si le ls que tu utilises est celui de gnu (/opt/gnu/bin/ls) ou celui de Solaris (/usr/bin/ls). Il est possible que le NAS présente des ACLs que GNU ls ne detecte ou affiche pas.

Citation:

---

Envoyé par jlliagre

Tu n'a pas dit si le ls que tu utilises est celui de gnu (/opt/gnu/bin/ls) ou celui de Solaris (/usr/bin/ls). Il est possible que le NAS présente des ACLs que GNU ls ne detecte ou affiche pas.

---

bonne idee...

Pourrais tu nous dire les ACLs qu il y a sur ton NAS ? en utilisant la commande "lsacl".
suivant les systeme, c est pas forcement cette commandes:
HPUX : lsacl
Solaris Linux : getfacl

Merci pour vos analyses...

Je passe ce post à "résolu" étant donné que les liens nous apportent une solution temporaire (clairement pas clean mais çà fonctionne)

Néanmoins, par curiosité j'ai lancé la commande dans un des répertoires utilisés et voici les informations renvoyées:

Citation:

---

/out>getfacl .

# file: .
# owner: root
# group: root
user::---
group::--- #effective:---
mask:rwx
other:---

---

Cordialement

VF

moi je ne comprends pas comment tu as le droit d’écrire dans le répertoire
:-)

Citation:

---

Envoyé par vfanelia

Je passe ce post à "résolu" étant donné que les liens nous apportent une solution temporaire (clairement pas clean mais çà fonctionne)

---

Es-tu connecté en tant que root lorsque tu copies les fichiers ? Si oui, peut-tu refaire les tests avec un compte standard (non root) ?
Pourquoi les scripts utilisent-t-ils les commandes de /opt/gnu/bin et pas les commandes standard (et donc supportées) ?