Forum Linux.debian/ubuntu SAMBA : Répertoires impossibles à supprimer

Posté par (page perso) .
Tags : aucun
0
9
août
2004
Bonjour à vous,

Mon serveur est en Sarge et Samba est installé. Depuis Windows l'accès aux dossiers se passe sans problème. En revanche, j'ai remarqué les problèmes suivants sous Linux Debian :

1/ Je crée un dossier dans lequel je crée un autre dossier et j'essaye de supprimer le dossier parent : "device or resource busy". Même après un redémarrage, histoire d'éviter les verrous. Avec les fichiers, il n'y a pas ce problème.
Ce problème est répétable avec tous dossier contenant quelque chose.

2/ Via ssh, le propriétaire apparaît bien dans le répertoire partagé, mais depuis le client les fichiers appartiennent à root.

Voici quelques extraits de ma configuration :


============ /etc/samba/smb.conf
[donnees]
comment = /home/samba
path = /home/samba
valid users = moi, lautre
read only = No
wide links = No
create mode = 0777
============

============ /etc/fstab
//serveur/donnees /mnt/serveur smbfs auto,rw,username=moi,password=monpass,umask
=0000,fmask=0777,dmask=0777
============


Des idées ?
  • # Début de solution pratique

    Posté par . Évalué à 4.

    >1/ Je crée un dossier dans lequel je crée un autre dossier et j'essaye de supprimer le dossier parent : "device or resource busy". Même après un redémarrage, histoire d'éviter les verrous. Avec les fichiers, il n'y a pas ce problème.

    Je te suggère d'arrêter le service samba avant d'essayer la suppression. Bon, ça, c'est juste si tu veux une solution tout de suite, immédiatement utilisable, ce n'est pas jouable à long terme.
    • [^] # Re: Début de solution pratique

      Posté par (page perso) . Évalué à 2.

      Sur le serveur, via ssh, il n'y a aucun problème. Mais si j'arrête le service Samba, je ne peux plus y accéder depuis le poste client.

      Donc si j'arrête ce service, je ne peux pas plus supprimer...
      • [^] # Re: Début de solution pratique

        Posté par . Évalué à 3.

        Ah, d'accord, je n'avais pas compris que ce message d'erreur était obtenu en cas de suppression depuis le poste client... Bon, à mon avis, cela doit être la traduction, par samba, de l'impossibilité, sous UNIX/Linux, de supprimer un répertoire non vide (sauf par unlink, par le root, et encore, c'est fortement déconseillé).
        Manifestement, samba traduit (en gros) un ordre de suppression par "rm", et non "rm -rf", ce qui est plutôt logique (pour éviter la suppression accidentelle de fichiers).

        Bon, si tu veux y remédier, je pense que ta seule solution (à moins que Samba soit reconfigurable sur ce point?), c'est d'imposer à tes utilisateurs de ne jamais supprimer de répertoire non vide. Cela dit, je n'ai jamais installé de Samba....
        • [^] # Re: Début de solution pratique

          Posté par (page perso) . Évalué à 2.

          Désolé de te contredire, mais :

          1/ création du répertoire "a".
          2/ entrée dans "a".
          3/ création du répertoire "b".
          4/ Remontée d'un cran ("a" devient visible).
          5/ Suppression de "a" ===> ERREUR.
          6/ entrée dans "a" ("b" devient visible).
          7/ Suppression de "b" ===> ERREUR.

          "b" est vide mais ne peut être supprimé.
  • # Fâââââm je vous aime :-/

    Posté par (page perso) . Évalué à 2.

    J'ai trouvé la solution au problème : il s'agissait de DEUX élements perturbateurs qui m'empêchait de supprimer les répertoires.

    L'utilisation le lsof en tant que root m'a permi de voir que kdeinit et famd verrouillaient le répertoire. Le processus kdeinit était visible en root et en utilisateur tandis que le processus famd n'était visible que pour root.
    Comme en plus mes tests en root sont toujours en console, root ne bloquait pas avec kde... Dur de se dépétrer dans deux problèmes croisés :-o
    famd s'accroche dès le démarrage sur les répertoires, tandis que kdeinit ne reste qu'après être rentré dans le répertoire.

    Solutions :

    1/ Renommer le répertoire juste avant de le supprimer. Cela suffit à "semer" l'instance de kdeinit.
    Note : un kill sur kdeinit est une mauvaise idée...

    2/ Annuler le démarrage de famd, ou l'arrêter juste avant de faire la suppression.

    Une question reste en suspens : quels trucs se servent de famd ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.