Office Starter Et Dsm4.2-3202

[SAMU]

Bonjour,

Ce problème ne m'a été signalé que depuis la mise à jour du DS413 vers DSM4.2-3202.

A partir de WORD et EXCEL STARTER 2010, il est impossible, pour les utilisateurs déclarés administrateurs sur le DS413, de sauver les fichiers dans un répertoire pour lequel a été coché: "Permettre la modification de la liste de contrôle d'accès Windows".

On obtient le message "Accès refusé. Contactez votre administrateur".

Ce problème est présent pour tous les PC (sous W7 et VISTA).

Depuis un OFFICE 2010 NON-STARTER ce problème ne se manifeste pas.

OFFICE STARTER utilise, lui, la virtualisation (disque Q:) : ce pourrait être une piste.

Les seules solutions que j'ai trouvées, mais qui ne me satisfont vraiment pas, sont

- soit de décocher sur le SYNO "Permettre la modification de la liste de contrôle d'accès Windows",

- soit de déclasser l'utilisateur dont je retire les droits d'administrateur sur le SYNO.

Avez-vous rencontré aussi ce problème ?
Qui aurait une explication...et si possible...une solution ?

SAMU

P.S. Petits détails interressants:

- un fichier de 0 octet; du nom demandé dans "Enregistre sous", est créé dans le répertoire avant le message de refus;

- si le répertoire dispose d'une corbeille, un fichier temporaire (la sauvegarde du document) contenant le document s'y trouve (comme c'est aussi le cas quand tout est OK).

Modifié le 11 mars 2013 par SAMU

[CoolRaoul]

Peut-être qu'office starter interprète mal l'autorisation *implicite* donnés aux utilisateurs du groupe administeurs d'accéder aux dossiers.

Une piste: essayer d'ajouter une autorisation *explicite* sur ces dossiers en ajoutant une entrée d'ACL donnant droit de lecture/ecriture (ou plus) sur ces dossiers à ce groupe

[SAMU]

Ca ne change, hélas, rien !

Le dossier est accessible par défaut à "Tout le monde". J'ai essayé en rajoutant le nom de l'utilisateur, le groupe etc...le problème reste inchangé.

De toute façon, c'est le système qui vérifie les droits. Mais cela ne se produit que pour OFFICE STARTER. Par exemple OFFICE 2010, NOTEPAD, WORDPAD etc... enregistrent sans problème !

Modifié le 11 mars 2013 par SAMU

[CoolRaoul]

Ca ne change, hélas, rien !

Le dossier est accessible par défaut à "Tout le monde". J'ai essayé en rajoutant le nom de l'utilisateur, le groupe etc...le problème reste inchangé.

Le test que je demandais de faire était d'ajouter explicitement une ACL pour le groupe "administrateurs" ? Faudrait essayer même si ça peut avoir l'air bizarre.

De toute façon, c'est le système qui vérifie les droits. Mais cela ne se produit que pour OFFICE STARTER. Par exemple OFFICE 2010, NOTEPAD, WORDPAD etc... enregistrent sans problème !

Ce n'est pas obligatoire: une application (de la part de Microsoft on peut s'attendre a tout) peut tout à fait récupérer, d'une part la structure de donnée correspondant à l'ACL, d'autre part la structure correspondant a la liste de droits du process et tenter de vérifier elle-même les droits, plutôt que l'approche, a priori plus "naturelle", de tenter l'ouverture du fichier en écriture et d'intercepter l'éventuelle erreur .

Si tu veux savoir exactement ce qui ce passe je t'invite a utiliser process monitor sur le PC, c'est un outil absolument extraordinaire pour "espionner" ce que fait un process en temps réel.

Il va te permettre d'auditer quels sont les API invoquées par Office et voir les codes retour. Ce devrait aider pour voir exactement ou ça et ce qui coince.

En parallèle, activer la trace SMB dans DSM (panneau de conf -> Win/Mac/Nfs -> Service de fichiers windows -> activer le journal des transfert) peut aussi aider à identifier ce qui se passe.

Modifié le 12 mars 2013 par CoolRaoul

[SAMU]

Merci CoolRaoul pour tes précisions.
J'avais bien essayé en rajoutant le nom de l'utilisateur, le groupe etc. dont le groupe "administrateurs", en fait nommé "administrators" (ceci me rappelle d'ailleurs un bug de traduction que j'ai déjà rencontré mais qui ne semble pas recouvrir la situation observée).

J'ai suivi ta suggestion et "tracé" avec le journal de transfert.
- aucune erreur n'est rapportée;
- si je décoche "Permettre la modification de la liste de contrôle d'accès Windows", pour que Word enregistre, toutes les opérations sont reportées comme réalisées par l'utilisateur de session.
Sur ton conseil, j'ai téléchargé "process monitor". Je regarderai dès que possible.

De toute façon, ce qui me dérange le plus c'est que tout laisse à penser que la mise à jour vers DSM4.2-3202 est en cause.
Comme j'ai déjà beaucoup de mal à obtenir une réponse concrète de Synology à un gros problème de pourrissage de disque par TimeBackup (2 Go de mangé chaque heure à chaque backup incrémental, sans fichier source modifié), j'attends pour leur soumettre ce nouveau problème que le premier ait avancé.

Modifié le 12 mars 2013 par SAMU

[Gonz]

Le problème est manifestement un bug relevé aussi sur le forum Synology:

http://forum.synology.com/enu/viewtopic.php?f=49&t=65463&start=0

[Gonz]

Ce post fait doublon avec celui dans "Accès aux données".

La solution au problème pour l'instant c'est de désactiver la fonction ACL sur les dossiers partagés.

[SAMU]

Merci, Gonz, pour ce retour et ton raccourci.

Mais je n'ai pas trouvé le post "Accès aux données" auquel tu fais allusion.

[CoolRaoul]

Merci, Gonz, pour ce retour et ton raccourci.

Mais je n'ai pas trouvé le post "Accès aux données" auquel tu fais allusion.

Ca doit être celui-la:

[CoolRaoul]

Au cas ou ça pourrait interesser certains, j'ai pu reproduire le problème et identifier précisément l'instant où l'erreur se produit.

(Merci Process Monitor)

Et ça confirme ce que je soupçonnais: Microsoft Office fait appel a une API Windows pour récupérer la structure de sécurité associée au fichier alors qu'il me semble quand même plus simple de procéder par "essai et erreur" (en tout cas c'est comme ça que je m'y prendrais personnellement!)

http://msdn.microsoft.com/en-us/library/ff549298.aspx

Bien entendu, cela n'innocente nullement Synology: DSM, et plus particulièrement samba, ne devrait pas retourner "ACCESS DENIED" dans cette situation.

Modifié le 15 mars 2013 par CoolRaoul

[SAMU]

Je reçois ceci du support SYNOLOGY à qui j'avais soumis le problème:

"If this issue is only happened for the shared folder with ACL enabled, that's a known bug and we will try to come out a hotfix soon. Sorry for your inconvenience."

("Si cette situation s'est seulement produite pour le dossier partagé avec ACL actifs, c'est un bug connu et nous essaierons de sortir un correctif rapidement. Désolé que cela vous crée problème.".)

Donc, wait and see ...

En attendant, voici une solution qui me permet de ne pas abjurer les ACL:

- Je crée un disque virtuel géré par Windows sur le SYNO (disque émulé dans un fichier .VHD).

- J'ai alors comme seule gestion des ACL celle de Windows.

OFFICE y retrouve alors les siens !

Modifié le 15 mars 2013 par SAMU

[Gonz]

Question, C'est quoi le problème de désactiver les ACL sur les fichiers partagés?

[SAMU]

La réponse est dans: "ça sert à quoi les ACL ?"

Modifié le 18 mars 2013 par SAMU

[Gonz]

La réponse est dans: "ça sert à quoi les ACL ?"

Euh...ça c'est une question non?

[SAMU]

En effet, en y répondant tu auras réponse à ta propre question.

Modifié le 22 mars 2013 par SAMU