NFS permission problem on MacOS Sierra #8061
Comments
|
I'm getting very similar behavior with CentOS 6 and 7 guest OS operating systems. My host operating system is also macOS Sierra. I've tried downgrading/upgrading Vagrant and Virtualbox. The problem seems to be made worse by restarting my host/physical machine—everything on the shared partitions becomes undeletable as far as I can tell. I have a few interesting ways to make the files deletable again:
I'm not sure this is really a Vagrant issue so much as a macOS Sierra nfsd issue, but hopefully the Vagrant community might be able to put information together to come up with a bug report and/or workaround. |
|
i can confirm @lightster 's observations. same issues and solutions here with running ubuntu on parallels. |
|
I have this issue too, CentOS 6.8 and Mac OS Sierra. |
|
Confirmed with various Vagrant and Virtualbox versions and several guest OSes. Disabling NFS lookupcache seems to work, but the performance is unbearable. Recursive listing and then deletion seems to work as well. I found it the fastest to do |
|
I wonder when someone from Vagrant team will lookup into this, can't properly work on OSX with Vagrant |
|
@crashev it seems, that its a OSX Bug, not a vagrant ones. Until now there are no known working workarounds, with an acceptable performance |
|
@lightster mentioned a workaround - from your host machine (i.e. macOS) if you perform the following operation in the root of the shared folder: Then that appears to refresh all the NFS links, meaning you are able to operate as normal inside Vagrant again. It isn't ideal, but I've been doing that pretty successfully for a while now. |
|
@araines just chcked ls -lR but it does seem not to work for me, still a lot of permission denied when trying to delete folder like vendors/ in my php project, but found that's because ls -lR does not go into directories with dot like .git in this case it's better to use:
|
|
I tried quite a few things, and ended up removing vagrant (with instructions from the website) and installing 1.9.1 with virtualbox 5.1 and that worked for me - now my setup works as expected, not sure if that helps anyone. |
|
@joshuasmickus could you please elaborate? As far as I know, vagrant 1.9.1 supports virtualbox up to 5.0, not 5.1 |
|
After spending almost a day trying to debug this thing, it seems I have a "solution". The reason we kept on searching was that I was having this exact issue as described in this bug report, but a colleague of mine, also on Sierra, was having no problems: there had to be something more going on. So, last thing we tried that seems to have fixed it: On my host machine the directories that were shared were owned by the group "staff" whereas on my colleague's machine the shared directories on the host were owned by group "wheel". So I've changed the group owning the shared directories on my machine to "wheel" and now it works. I don't claim to fully understand why this matters, because in /etc/exports I see the NFS exports map the group to group ID 20, which is actually "staff" on my machine. But I'm done with this, it works and I'm not touching it any further... I hope someone here can confirm whether it works for them though! Edit: Bummer, it doesn't appear to be entirely solved. Still getting the problem sometimes, even though somehow the situation does appear to have improved for some amount of time... |
|
@kazgurs - It definitely supports 5.1.x. From the docs page:
@joshuasmickus For what it's worth, I'm still seeing the issue on my setup with VirtualBox 5.1.2, Vagrant 1.9.1. I think the problem is definitely intermittent so we have to be careful when seeing the problem go away for a while. Too bad the workaround with the group didn't work out either :/ Maybe the effect of doing a chown on the files were having similar effects to the ls -lR command. |
|
@arendjr can you please investigate further what's different to your colleagues's machine? Right now I'm running a |
|
Been trying to debug this further into the NFS all morning. I can use Unfortunately, I can't for the life of me figure out how to use the equivalent of rpcdebug on osx. I've tried upping the verbosity of nfsd on osx but it doesn't go anywhere as verbose as on linux using rpcdebug... No idea how I can look into this further on the server side since there's no logging available, but that looks like where the problem would lie... |
|
Srana at my work suggested the following: Right click on the folder which has the permissions error, and then click "Get info". At the bottom, give it "Read & write" access for "Everyone". This should solve the permissions error |
|
@joshuasmickus I can confirm I'm having some success by doing that... but I'm holding my breath whether it'll last this time. Fingers crossed! @whizkid79 I wish I could... My colleague and I are running the exact same virtual machine image now, and we cannot find any further changes on our hosts... Right now I'm sincerely out of ideas of what to try next. I can only hope Joshua's solution will last for now... |
|
One more update: My colleague has suddenly gotten the problem as well. I'm starting to believe no Sierra users are truly immune here... And @joshuasmickus' workaround was also only a temporary relief... |
|
Same here, i can reproduce the problem on my own local boxes but also on totally new ones (loading any vagrantfiles from any projects on the web, vagrantfiles that worked perfectly for years, and now they fail due to NFS issue.) |
|
One workaround is to use unfs3d instead of the nfsd server included with MacOS. brew install unfs3
sudo nfsd stop
sudo unfsd -e /absolute/path/to/some/exportsThe |
|
@matleh can you also put the vagrantfile command? |
|
Spilled couple days on this, but I managed to get it working (for now at least):
EDIT: Nope... Temporary fix... |
|
@rozagh actually, I don't use Vagrant - this problem also occurs with docker-machine-nfs. I am back to stock nfsd and running |
|
This thread might be related: https://discussions.apple.com/thread/7760267?start=0&tstart=0 |
|
Reports in #8788 are that that bug is fixed in High Sierra 10.13.2 Beta 2. Can anybody verify if this bug is fixed there as well? |
|
I sure hope so. Upgrading to that load this weekend, will very this one as well. |
|
Upgraded to High Sierra 10.13.2 Beta 2, removed my cronjob that would periodically do an |
|
@jfbibeau Have you had the problem since? |
|
@emileber I'm happy to report I haven't seen this in almost 2 weeks of using High Sierra. It's completely fixed! |
|
I can confirm, too -- I've been using High Sierra (both beta2 and beta3) for a week with zero NFS issues. Woohoo! |
|
Is this an OPEN beta ? I mean can we upgrade straight from Sierra to High Sierra beta 3 without a developper account ? |
|
I had to sign up for a developer account, but it was free. |
|
thanks @chrisfromredfin So just to be clear, with this beta, is it safe to upgrade or there are still pending issues with High Sierra ? |
|
I have upgraded to beta so far no issues. and it solved this issue...
2017年11月27日 22:47，"Tristan Bessoussa" <notifications@github.com>写道：
… thanks @chrisfromredfin <https://github.com/chrisfromredfin>
So just to be clear, with this beta, is it safe to upgrade or there are
still pending issues with High Sierra ?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#8061 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA0FWpCTmO-CaK4dkUW_tt2ndXsTJ_Zbks5s6st_gaJpZM4LAXYg>
.
|
|
It would seem this issue has come to replace it: #8788 |
|
@sinisilm That one is also fixed in High Sierra latest beta. |
|
Be careful with High Sierra as there is a major security breach right now: https://www.macrumors.com/2017/11/28/macos-high-sierra-bug-admin-access/ |
|
Also, I recommend installing the latest High Sierra patch from Apple, which fixes the security vulnerability that @emileber mentioned: https://support.apple.com/en-us/HT208315 |
|
Just got this from Apple - apparently it is fixed in 10.13.1 GM. (I can't test it atm since I'm deferring 10.13 due to APFS compatibility issues.) |
|
Unclear if this is the same bug as what I am seeing, but it seems close. I am on High Sierra 10.13.3, using nfs (with bindfs extension) and Vagrant to develop. The problem I have is, when I edit a file on the host machine that is in a folder to sync over nfs to the VM, it takes > 7 seconds for the change to go through, and I get an I/O error on the file while I am waiting. BUT if I change the file, then immediately do an Oddly, if I just do an Any ideas how I can fix this? I see a bunch of workaround above (like running a cron job to |
|
@pnoeric it looks like a bug, but it's definitely not related to this issue. You should open a new one. |
|
I have been having somewhat similar issues - but mostly just a seemingly large lag between changing a file from the outside and it being detected on the inside - especially with IDEs using atomic writes. If you open a new issue, please post a reference back here. |
|
@chrisfromredfin that's another issue well known to mac users - the lag / sync between mounted volumes. This issue has been fixed on the new MacOS versions, no point in keeping it open. Should be closed. |
|
Closing this up as it should be resolved upstream now. Cheers! |
|
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
ghost
locked and limited conversation to collaborators
and others
Vagrant version
Vagrant 1.9.0
Host operating system
MacOs Sierra 10.12.1
Guest operating system
Linux - Debian 8.5 - mokote/debian-8 (version 8.5)
Vagrantfile
Debug output
And on MacOS, file /etc/exports contains:
Expected behavior
I should be able to remove any file mounted in nfs share directory.
Actual behavior
I can only delete some files - seems like only in root directory, anything below can
not be deleted.
Steps to reproduce
Everything is in debug.
References
The text was updated successfully, but these errors were encountered: