Mappen onzichtbaar op windows share

[dinux]

Beste allemaal,

De situatie is als volgt:
Ik heb een Synology die shares deelt door mijn netwerk. Alle shares hierop zijn te benaderen via het guest account. Los van dat alles heb ik een download server die 's nachts de benodigde bestanden binnenhaalt en lokaal neerzet.

Wanneer de downloads klaar zijn laat ik een (Python) script de bestanden vanaf de lokale server verplaatsen naar de synology over smb. Dit werkt prima maar er gebeurd iets raars bij de mappen. Als ik op een willekeurige Windows computer de Synology share benader zie ik dat daar inderdaad mijn gedownloade bestanden staan, maar de mappen zelf zijn verborgen.

Dit gebeurd enkel met mappen, bestanden gaat prima. Voor zover ik zie ligt het niet aan de rechten op de Synology of op de download server. Windows geeft zelfs aan dat het niet alleen verborgen mappen zijn maar zelfs systeem mappen.

Ik heb inmiddels vanalles geprobeerd van NFS shares tot SCP en FTP, maar dat maakt het rechten probleem alleen maar lastiger op de synology. Heeft er iemand enig idee hoe en waarom de Synology (of downloadserver) de mappen als Systeem mappen neerzet?

Ik ben een beetje ten einde raad, alle hulp is welkom.

[Viper®]

welk account gebruikt het python script om naar de nas shares te schrijven

[MikeOO]

En als je via DSM naar Gedeelde mappen gaat en dan de betreffende map selecteert en voor bewerken kiest.
Staat daar dan toevallig het vinkje aan bij

Verberg deze mappen.....
of
Mappen en bestanden verbergen......

Mogelijk dat de hoofdmap deze optie standaard aan heeft staan waardoor de aangemaakte mappen dit recht ook krijgen.

En is er een reden waarom het Guest account rechten heeft op alle mappen. Maakt niet uit verder maar lijkt mij juist om dit account zo min mogelijk rechten te geven of helemaal niets en zelf een account aan te maken voor dit soort acties.

[ Voor 47% gewijzigd door MikeOO op 16-05-2014 17:25 ]

[dinux]

MikeOO schreef op vrijdag 16 mei 2014 @ 17:20:
En als je via DSM naar Gedeelde mappen gaat en dan de betreffende map selecteert en voor bewerken kiest.
Staat daar dan toevallig het vinkje aan bij

Verberg deze mappen.....
of
Mappen en bestanden verbergen......

Mogelijk dat de hoofdmap deze optie standaard aan heeft staan waardoor de aangemaakte mappen dit recht ook krijgen.

Beide opties staan uitgevinkt. Als ik zelf een map aanmaak als root via de downloadserver op de share dan zie ik hem namelijk wel gewoon verschijnen in Windows.

Python script draait als root, triggered bij een cronjob.

[MikeOO]

En wordt dit script gestart vanaf de NAS of vanaf de downloadserver. Dit zal zeker uitmaken qua rechten.

Zelf gebruik ik een script via LFTP. Ik kopieer alle opnames op een bepaalde tijd van een Humax PVR decoder naar mijn nas. Hier gaat dit altijd goed met kopieeren van mappen en bestanden.

Misschien heb je hier iets aan.

En is het een idee om je NAS ook het downloaden te laten doen. Daar zijn ze erg goed in en scheelt je weer een server.

humax.sh (in home/script folder gezet.)

code:

#!/bin/bash
/opt/bin/lftp -u humaxFTP,0000 -e 'mirror -X 0.nts -X 0.ts --Remove-source-files --verbose --log=/volume1/opnames/opnames.log "/My Video/" /volume1/opnames'  192.168.0.109

Cronjob

code:

0   3   *   *   *   root    sh /volume1/homes/scripts/humax.sh >>/volume1/homes/scripts/humax.log 2>&1

[ Voor 78% gewijzigd door MikeOO op 16-05-2014 17:31 ]

[Viper®]

Python script zal op de download server draaien. Ik ben dan ook benieuwd met welk account hij de smb verbinding naar de nas opzet.

[dinux]

Alles wordt gedaan onder root (aangezien het toch intern is) dus ook de SMB/CIFS. Die wordt gestart door Debian zelf d.m.v. fstab.

Vanaf de linux server gezien ziet een map op de share er zo uit:

code:

drwxrwxrwx 2 1000 users      0 May 16 17:32 testmap

[Viper®]

Ik ben geen linux expert, kan het hier mee te maken hebben:
http://forum.qnap.com/viewtopic.php?t=19163

That's because you should set the folders to 777 and the files to 666, otherwise SMB will tread the files as system and hidden.
I've created a small script for doing this, but alas I'm not able to retrieve it at the moment.

[dinux]

Viper® schreef op vrijdag 16 mei 2014 @ 17:40:
Ik ben geen linux expert, kan het hier mee te maken hebben:
http://forum.qnap.com/viewtopic.php?t=19163
[...]

Hoewel het er alle schijn van heeft lijken de rechten gewoon in orde. Ik kan een map die vanaf de download server komt in Windows gewoon bewerken, verwijderen of aanpassen, en dat geldt ook voor de bestanden erin.
Zelf het ik het idee dat er een speciale bit wordt getoggeld die Windows herkend als systeemmap, los van de rechten, maar dat zeg ik puur op gevoel.

[MikeOO]

En als rechtermuisknop in Windows verkenner op een map klikt en dan eigenschappen.
Staat daar miscchien verborgen aangevinkt. Tevens kun je daar ook de rechten bekijken mogelijk dat je daar nog iets in vindt.

[dinux]

Dat staat inderdaad aangevinkt, maar dat geldt voor alle mappen via de Synology. Aan de mapeigenschappen is het ook niet af te lezen, maar enkel aan het feit dat ze pas verschijnen nadat ik 'Windows systeem mappen weergeven' aanzet in Windows verkenner.

In Linux of DSM zelf is verder niks te zien hiervan, en het lijkt dus echt alleen een Windows dingetje.

[MikeOO]

Mogelijk dat je dan met het script dit vinkje kan laten omzetten na een kopieslag. Want het is geen standaard iets van Synology. Heb het zelf nooit meegemaakt en wordt toch heel veel op uitgevoerd en aangemaakt.

Misschien het script anderom laten starten. Bv dat je deze vanaf de NAS start ipv Downloadserver. Mogelijk dat het dan beter gaat.

[dinux]

Dankje Mike, dat heb ik nu gedaan en dat lijkt, gek genoeg, wel te werken.

[MikeOO]

Mooi dat dit wel werkt. Het zal toch een rechten probleem zijn en dat hij rechten meekrijgt waar de NAS dan weer iets anders mee doet.

Omdat je nu vanaf de NAS zelf start krijgt hij wel de juiste rechten mee.

[dinux]

Uiteindelijk zal het inderdaad een rechten probleem zijn maar niet een die zo makkelijk is aan te tonen. Bedankt voor de tip.