so I guess it’s NOT safe to update on 20 september… tick tock
The simple reason why it doesn’t work as normal user but works as root is a change of permissions on /Volumes.
In older version of the OS the permission are as follows:
But in the Beta MacOS Sierra it is:
It both case the directory is owned by root.
If you in MacOS Sierra changes it to drwxrwxrwxt, it works but after reboot, it’s set back to the non-working permissions.
I installed the release candidate earlier today.
I’ll try setting the permissions back to workable permissions and see if they remain after a reboot.
If they don’t there are multiple way to work around, for instance setting SUID bit for executables, having a root cronjob set the settings ever so often, etc.
The change of permissions didn’t survive a reboot!
Just found this:
Apple have closed my bug report, stating:
This issue behaves as intended based on the following: It was requested by security, you can no longer create items in /Volumes unless root.
Just tried with a dirty hack, adding a chmod to root’s cron.
As expected, it did work.
jmy-mp:/ johan$ sudo crontab -l
- /bin/chmod a+rwxt /Volumes
Roon starts fine and can mount the SMB shares.
However, this is obviously not a permanent solution.
So it would seem like Roon has to access SMB shares directly without mounting, if that is possible in MacOS…
we can mount it elsewhere… but the problem is that we wanted to mount it in /Volumes so you can see/unmount it in Finder
trying to figure out how Finder can do this via the cmd-k thing…
I’ve installed sierra 10.12 on my macbook pro (13-inch, Early 2011). And now I have a lot of problems:
- Roon cannot find my synology DS2014 play anymore.
- When I play my Roon it crashes.
Can you help me?
You will find information about Sierra and NAS in other threads . . . it is being fixed shortly.
Hi, I’ve merged you post into this existing topic, you will see the issue you reported is being worked on and for now there is a workaround (see qdtjni Johan N) post above.
Thnx, i’m looking forward to it. When should it be operational?
If you want to make the workaround persistent through reboots you can run the following (very long command) in Terminal:
sudo $SHELL -c “crontab -l 2>&1| grep -v “/bin/chmod a+rwxt /Volumes” > /tmp/foo.bar; echo “* * * * * /bin/chmod a+rwxt /Volumes” >> /tmp/foo.bar; crontab /tmp/foo.bar; rm /tmp/foo.bar”
Note that it must be pasted as ONE line into terminal and I take no responsibility for it.
If you later want to remove the fix, in a terminal run:
sudo $SHELL -c “crontab -l 2>&1| grep -v “/bin/chmod a+rwxt /Volumes” > /tmp/foo.bar; crontab /tmp/foo.bar; rm /tmp/foo.bar”
tried your script but it throws a
“/tmp/foo.bar”:0: bad minute
Not being an expert on the comandline, what can I do?
An update, somehow.
My initial problem was that Roon was not able to connect to my SMB share on my DLink NAS. My Mac is on Sierra.
On Finderm, I was able to map my NAS folder but the same did not work on Roon.
Then I figured out that I could use the ‘Local Folder’ setting to browse to my already mapped share. Voila, everything’s working now.
I don’t get that error. Did you make sure you pasted it as one line into the Terminal?
Build 161 just went live with a fix for this, guys.
Let us know if you have any additional issues, and thanks for everyone’s patience.
After upgrading Roon, removing my workaround and rebooting -
Roon works fine without workaround again! Good work!
After upgrading MacOS Sierra to 10.12.1 the same issue happened again!
Just did a check on 10.12.1:
Can you confirm that you’re running the latest Roon? What is the exact error message?
It seems to work normally now (status: connected), most probably a temporary error.
Sorry for the inconvenience…
A post was split to a new topic: NAS Issue - “Unable detach Volume”