Synology-Forum.nl
OS Specifieke ondersteuning => Mac OS X => Topic gestart door: Briolet op 13 mei 2015, 09:58:11
-
Ik zette altijd de share zelf bij de startup onderdelen bij het inloggen onderdeel in gebruikers en groepen. Op zich werkt dat goed, maar op die manier worden de windows van de shares altijd direct geopend na het koppelen. Dat kan soms vervelend zijn bij veel shares.
Als je ze via Applescript koppelt is dat probleem er niet, dus ben ik een tijdje geleden aan het schrijven gegaan. Of eigenlijk een aanpassing gedaan op reeds bestaande scripts. Wil je het script ook gebruiken, kopieer dan onderstaand script in een nieuw applescript venster:
(*
Mount shares to the desktop. Finder will ask for a password the first time.
You than can choose to store it in the keychain to let it automount the next time.
Duplicate the "mount_share" command to add more shares.
*)
mount_share("smb", "account", "nasnaam.local", "sharenaam-1")
mount_share("smb", "account", "nasnaam.local", "sharenaam-2")
on mount_share(protocol, account, server, share)
set x to 0
-- try a few time in case the server has to wake up first.
-- don't do anything if the share is already mounted
repeat until x > 4 or mounted_shares() contains share
tell application "Finder"
try
mount volume protocol & "://" & account & "@" & server & "/" & share
on error
set x to x + 1
delay 30
end try
end tell
end repeat
end mount_share
on mounted_shares()
tell application "System Events" to get the name of every disk whose free space > 1
end mounted_shares
Pas alleen de regel: "mount_share("smb", "account", "nasnaam.local", "sharenaam-1")" aan aan je behoefte. Dupliceer daze regel voor elke share die je wilt mounten. (2 stuks in het voorbeeldscript)
Vervolgens kies je "exporteer" uit het "Archief" menu en verander de structuur van "script" naar "Programma". Nu exporteert hij het script als programma.
Vervolgens zet je dit programma bij de inlog onderdelen. Bij elke opstart worden de shares nu ook vanzelf gemount, maar nu blijven de vensters lekker dicht. Je kunt de shares ook openen door het programma gewoon te starten.
[attachimg=1]
-
Ik ken dit 'probleem' van het openen van al die vensters.
Dus heb ik het een tijdje via Hazel gedaan, maar dat was ook niet ideaal.
Recentelijk gebruik ik hiervoor de app Mountain (http://appgineers.de/mountain/), dat behalve mounten nog een aantal extra features kent. Zoals het remounten van shares na een netwerk onderbreking (vooral in situaties wanneer je alleen van wifi afhankelijk bent is dat erg handig, zie je ook gelijk wanneer je wifi verbinding weer beschikbaar is).
-
@Briolet
Is het ook mogelijk om via AFP te koppelen? Of heb jij er bewust voor gekozen om via SMB te koppelen?
Mvgr,
Phoenix77
-
Thanks Briolet, gaan we proberen, vraag me wel nog af waarom het vinkje bij verbergen niet werkt in de huidige opzet. ??
-
Het werkt ook met AFP. SMB was een willekeurige keuze in het voorbeeld.
Sinds Mavericks is SMB echter het voorkeurs protocol tussen mac's, als beide protocollen via bonjour worden aangeboden. Als apple afscheid lijkt te nemen van afp, lijkt het me dat je shares ook gewoon met smb moet verbinden.
-
Hoe reageert jouw script op het moment dat de nas down is ?
Ik had ooit een soortgelijke setup maar als de nas uit was en ik bootte mijn mac dan hing deze erg lang.
Ik ping nu eerst alvorens te mounten via een shellscript.
-
Hoe reageert jouw script op het moment dat de nas down is ?
Volgens mij merk je er weinig van en start de rest door. (Nooit getest) Hij geeft wel elke 30 sec. een melding op scherm dat hij geen verbinding kan maken. (5x per share die hij moet mounten)
Maar als je perse de nas op de desktop wilt hebben, heb je toch al een probleem als de nas down is. Je kunt ook gewoon één poging doen en dan opgeven. Dat is ook genoeg als je de nas nooit in slaapstand zet.
-
Het script geschreven en het werkt bijna perfect.
Om een of andere reden lukt het niet om mijn home map op de synology via dit script te mounten.
Hebben anderen hier ook last van?
-
Geen idee maar een home map is eigenlijk geen share maar een link naar "homes/<naam van de gebruiker>", misschien dat dit er iets mee te maken heeft.
Je zou kunnen proberen "homes" te mounten, dan zie je daar alle home directories van alle gebruikers staan, echter kun je alleen die benaderen waar je rechten op hebt.
-
het vreemde is als ik de home map benader via "gedeeld" en dan de share home aan klik deze daarna wel gemount is.
Als ik dan de eigenschappen bekijken zie ik smb://diskstation.local/home staan.
homes mounten lukt niet
-
Inderdaad vreemd. Als ik een niet of wel bestaande share invul, krijg ik het dialoog om een wachtwoord in te vullen. (Op de mac waar ik nu zit heb ik geen WW opgeslagen) Echter, als ik 'home' gebruik, krijg ik geen dialoog, het script blijft ook niet hangen.
Als ik via appeltje-K smb://briolet@nasnaam/home invul, mount home wel correct. Dat script zou hetzelfde moeten doen, maar doet het niet.
-
Als ik in het script gewoon 'mount volume "smb://Briolet@nasnaam/home"' zet, werkt het wel. Het lijkt erop dat het woord 'home' een speciale betekenis in applescript heeft bij het samenstellen van de string waardoor er niets gebeurd.
Als je
mount_share("smb", "account", "nasnaam.local", "home")
in
mount_share("smb", "account", "nasnaam.local/home", "")
veranderd werkt het wel.
-
Heb in het script mount_share("smb", "account", "nasnaam.local/home", "home") gezet omdat hij anders in de loop blijft hangen
Helaas werkt niet, hij lijkt te blijven lopen, het programma blijft actief.
-
Ik ben er nu achter waar het probleem zit. Het zit in de regel:
repeat until x > 4 or (list disks) contains share
"list disks" is een lijst met reeds gemounte disks. Echter, daar staat altijd al een 'home' tussen die de mac zelf aanmaakt. Daardoor gaat hij ook niet proberen een share met dezelfde naam te mounten omdat hij denkt dat 'home' reeds gemount is.
-
Ok, ik heb het script in het eerste bericht nu aangepast zodat hij ook met 'home' werkt.
In tussen las ik dat het gebruikte commando (list disks) (http://applescript.wikia.com/wiki/List_Disks) depricated was en vervangen moest worden door: ‘tell application "System Events" to get the name of every disk’.
In de lijst met disks staan twee speciale disks: "net' en 'home'. Beide zijn geen echte volumes en hebben 0 byte vrije ruimte. Dus als die disks zonder vrije ruimte uitgesloten zijn, kan het script onderscheiden tussen deze 'home' van de mac en de 'home' op de nas.
De kans is alleen dat het nu mis gaat als je geen schrijfrechten op die share hebt waardoor hij met 0 byte vrije ruimte terug komt. Maar het lijkt me zeldzaam te zijn als je zo'n share wilt koppelen zodat ik wil uitzoeken of dit mis kan gaan.
-
Veel mooiere oplossing dan die ik snel even had bedacht.
Ik had een extra tellertje voor het aantal shares toegevoegd en het mount commando voor home als laatste in de rij opgenomen.
(very quick and very dirty)
on mount_share(protocol, account, server, share)
set x to 0
set y to 0
-- try a few time in case the server has to wake up first.
-- don't do anything if the share is already mounted
repeat until x > 5 or (list disks) contains share or y > 6
tell application "Finder"
try
mount volume protocol & "://" & account & "@" & server & "/" & share
set y to y + 1
on error
set x to x + 1
delay 30
end try
end tell
end repeat
end mount_share
Ga meteen jouw script even implementeren.
-
Het werkt ook met AFP. SMB was een willekeurige keuze in het voorbeeld.
Sinds Mavericks is SMB echter het voorkeurs protocol tussen mac's, als beide protocollen via bonjour worden aangeboden. Als apple afscheid lijkt te nemen van afp, lijkt het me dat je shares ook gewoon met smb moet verbinden.
Voorlopig blijk ik toch bij AFP want dan zie ik (op de Desktop) de bij de betreffende HD behorende icon wat voor een snellere herkenning zorgdraagt.
-
@Briolet
Het script werkt prima, alleen lijkt het niet goed te werken in een multiuser omgeving, waarbij dezelfde shares gemount moeten worden, echter enkel onder een ander OSX en DSM account.
Het script mount de eerst aangegeven share bij de tweede gebruiker maar het stukje
on mounted_shares()
tell application "System Events" to get the name of every disk whose free space > 1
end mounted_shares
lijkt daarna in een loop te blijven hangen.
Enig idee waar dat door kan komen?
Het is toch wel even wennen de overstap naar OSX ;D
-
Multiuser is sowieso een ramp bij mounten. De share wordt default nml niet binnen de user gemount maar via het top level van de mac. Andere users kunnen dan ook de gemounte share zien. Ze kunnen hem niet benaderen, maar wel onbedoeld unmounten.
Op het internet worden allerlei methodes genoemd om een mountpoint naar de usermap te maken en daar de shares aan te koppelen. Dan zien andere gebruikers het bestaan van die shares helemaal niet. Toen ik bovenstaand script schreef, heb ik ook een variant geschreven die de shares via zulke mountpoints aan de individuele user koppelde. Ik gebruik echter maar 1 useraccount op de mac dus waren die moutpoints voor mij meer spielerei. Ik weet niet eens meer of ik dat script goed werkend heb gekregen. (Ik zal daar nog eens naar kijken)
Een ander probleem op de mac is dat je per protocol en server, maar met één account kunt verbinden. Als ik een testuser op de nas heb die maar 1 share mag benaderen en ik heb die share gemount, dan kan ik via mijn eigen account op de nas geen share meer koppelen. De mak negeert mijn opgegeven accountnaam en probeert de volgende share te openen onder het account waarvoor reeds een verbinding bestaat.
Ik los dat nu op door het ene account via afp en het andere account via smb te koppelen. Een echte oplossing heb ik hier nog niet voor gevonden. Komt blijkbaar zelden voor dat vanuit één mac-account naar meerdere nas accounts gekoppeld wordt.
-
Toen ik bovenstaand script schreef, heb ik ook een variant geschreven die de shares via zulke mountpoints aan de individuele user koppelde.
Nu weet ik weer wat het probleem met mountpoints was. Dat loopt via shelscripts en die kunnen het wachtwoord niet automatisch uit de sleutelhanger halen. Bij alle voorbeelden die ik op het internet vond voor het creëren van mountpoints, stond het wachtwoord gewoon in het script. En dat is een absolute no-no in mijn belevenis hoe je met wachtwoorden moet omgaan.
Edit: De volgende functie haalt heel mooi het WW op uit de sleutelhanger, dus die hobbel is nu ook weg.
on getPW(server, account)
do shell script "security 2>&1 >/dev/null find-internet-password -a" & account & " -gs " & server & " | awk '{print $2}'"
return (text 2 thru -2 of result)
end getPW
-
Multiuser is sowieso een ramp bij mounten. De share wordt default nml niet binnen de user gemount maar via het top level van de mac. Andere users kunnen dan ook de gemounte share zien. Ze kunnen hem niet benaderen, maar wel onbedoeld unmounten.
Een half jaar geleden merkte ik, naar aanleiding van vragen over dit probleem elders op het internet, dat dit ook bij mij speelde. De oplossing was mount points te maken naar een locale folder. Ik kreeg het toen niet werkend omdat ik weigerde een hardcoded WW in het script op te nemen.
Echter, nu kan ik dat probleem niet meer reproduceren. Het lijkt erop dat Apple dit probleem opgelost heeft voor normaal gemounte schijven. :D
En dat merk ik nu ik mijn script om met locale mount-pointen te werken geheel werkend heb. :)
-
@Briolet Is dat hetzelfde script aan het begin van deze post, of is het een ander script.
-
Het is een kleine modificatie. Ik geef hem hier voor de volledigheid.
(*
Mount shares to the desktop. Finder will ask for a password the first time.
You than can choose to store it in the keychain to let it automount the next time.
Duplicate the "mount_share" command to add more shares.
*)
mount_share("smb", "account", "nasnaam.local", "sharenaam-1")
mount_share("smb", "account", "nasnaam.local", "sharenaam-2")
on mount_share(protocol, account, server, share)
create_mountpoint(share)
set PW to getPW(server, account)
set Fx to "mount_" & protocol
if protocol = "smb" then set Fx to "mount_smbfs"
set x to 0
-- try a few time in case the server has to wake up first.
-- don't do anything if the share is already mounted
repeat until x > 4 or mounted_shares() contains "mountpoint_" & share
tell application "Finder"
set myscript to Fx & " " & protocol & "://" & account & ":" & PW & "@" & server & "/" & share & " ~/mountpoint_" & share
try
do shell script myscript
on error
--display dialog myscript
set x to x + 1
delay 30
end try
end tell
end repeat
end mount_share
on mounted_shares()
tell application "System Events" to get the name of every disk whose free space > 1
end mounted_shares
on create_mountpoint(share)
set mounted to do shell script "test -d ~/mountpoint_" & share & " && echo yes || echo no"
if mounted = "no" then
do shell script "mkdir ~/mountpoint_" & share
else
do shell script "echo 'mounted'"
end if
end create_mountpoint
on getPW(server, account)
do shell script "security 2>&1 >/dev/null find-internet-password -a" & account & " -gs " & server & " | awk '{print $2}'"
return (text 2 thru -2 of result)
end getPW
Dit script genereert voor elke share een lege folder in je user folder op de mac die als mount-point dient. Ik weet nu echter niet of het een meerwaarde heeft op het eerste script.
-
Heb even zitten puzzelen met het script, maar ik krijg steeds de foutmelding No such file or directory" number -128 of No such file or directory" number -127
Ook als ik het commando mount_smbfs smb://workgroup;user:password@ nasname.local/share ~/mountpoint_share in Terminal invoer krijg ik de melding No such file or directory
de map mountpoint_share is door het script netjes aangemaakt en bestaat
Als ik in Terminal mount -t smbfs //user@ nasname.local/share ~/share doe werkt het wel, echter zodra ik het user:password doe krijg ik de melding no route to host.
Maak ik er daarna mount -t smbfs //workgroup;user:password@nasname.local/share ~/share dan krijg ik weer de melding No such file or directory
Struikelt het script wellicht over mijn wachtwoord?
-
Kan ik het script ook gebruiken als ik regelmatig niet in het eigen netwerk zit? Zonder dat ik om de 5 sec een foutmelding krijg? Het zou fijn zijn als het werkt niet als bij windows, is de share beschikbaar is hij te benaderen, zo niet dan niet..
-
Heb uiteindelijk maar het programma Mountain (http://appgineers.de/mountain/) aangeschaft om het probleem op te lossen.
Het gepuzzel begon me echt teveel tijd te kosten voor zoiets simpels, zijn er dus toch stiekum zaken die onder Windows beter voor elkaar zijn dan onder OSX ;)