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 CoinKoin . Évalué à 4.
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 Christophe HENRY (site web personnel) . Évalué à 2.
Donc si j'arrête ce service, je ne peux pas plus supprimer...
[^] # Re: Début de solution pratique
Posté par CoinKoin . Évalué à 3.
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 Christophe HENRY (site web personnel) . Évalué à 2.
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é.
[^] # Re: Début de solution pratique
Posté par CoinKoin . Évalué à 2.
# Fâââââm je vous aime :-/
Posté par Christophe HENRY (site web personnel) . Évalué à 2.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.