New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Duplicate folders in /Volumes upon unlocking vault in macOS 10.12 Sierra #464

Closed
viddo opened this Issue Mar 5, 2017 · 18 comments

Comments

Projects
None yet
10 participants
@viddo
Copy link

viddo commented Mar 5, 2017

Basic Info

This is a bug report.

I'm using macOS in version: 10.12.3 Sierra

I'm running Cryptomator in version: 1.2.4 (862)

Description

My vault have the mountname tmp, which I would expect to get mounted at /Volumes/tmp.
Before the unlock I have this:

 $ ll /Volumes/
total 24
drwxr-xr-x@  6 root     wheel   204B Mar  5 09:05 ./
drwxr-xr-x  34 root     wheel   1.2K Mar  5 08:54 ../
-rw-r--r--@  1 nicklas  admin   6.0K Mar  5 08:56 .DS_Store
lrwxr-xr-x   1 root     wheel     1B Mar  5 08:46 Macintosh HD@ -> /

But after unlock I for some reason end up with two directories as such:

 $ ll /Volumes/
total 28
drwxr-xr-x@  6 root     wheel   204B Mar  5 09:05 ./
drwxr-xr-x  34 root     wheel   1.2K Mar  5 08:54 ../
-rw-r--r--@  1 nicklas  admin   6.0K Mar  5 08:56 .DS_Store
lrwxr-xr-x   1 root     wheel     1B Mar  5 08:46 Macintosh HD@ -> /
d--x--x--x+  2 nicklas  wheel    68B Mar  5 09:05 tmp/
drwx------   1 nicklas  staff   2.0K Mar  3 10:20 tmp-1/

…where the unlocked files are located in tmp-1 instead of tmp

What I've tried so far*:

  • Close down any other applications
  • Check if there are apps/processes locking files in /Volumes/tmp (using lsof)
  • Relaunch finder
  • Restart cryptomator
  • Restart computer
  • Rename mountname in cryptomator (e.g. foo) -- in this case I end up with duplicated folders of foo and foo-1 instead.

*When locking the mount it leaves the empty /Volumes/tmp folder around, so have deleted it between each thing I've tried so that.

Any other idea/suggestion on how to troubleshoot and/or resolve this?

@tobihagemann

This comment has been minimized.

Copy link
Member

tobihagemann commented Mar 6, 2017

Thank you for your bug report! 👍 It was briefly mentioned here: #170 (comment)

My impression is that it's a Sierra bug and has nothing to do with Cryptomator per se. I'm able to reproduce the issue with "any" localhost WebDAV server.

Unfortunately, I'm out of ideas on how to troubleshoot/resolve this. ☹️ Of course, our long-term goal is to switch to FUSE #252, but I also hoped that there would be some fix/workaround.

@viddo

This comment has been minimized.

Copy link

viddo commented Mar 6, 2017

Yeah, that's very possible. I figured I'd report it at least, in case someone else have encountered a solution. Meanwhile I can work around it so it's not a show stopper.

Looking forward to the that FUSE feature, too. :)

Thanks for the prompt reply! 🙇

@Wurmdosungen

This comment has been minimized.

Copy link

Wurmdosungen commented Apr 1, 2017

I think that I found a workaround - at least it has been working for me for a few days, macOS 10.12.4 (16E195).

My vault is called Aleph. After unlocking the vault, I do a "lsof | grep Aleph". SInce Aleph is unlocked, it should return an empty output. Instead, it returns the following message:

lsof: WARNING: can't stat() webdav file system /Volumes/Aleph-2
      Output information may be incomplete.
      assuming "dev=32000004" from mount table

This stat attempt to /Volumes/Aleph-2 seems to trigger something, because now, after a few seconds, the Finder opens a message saying that the WebDAV server has been unexpectedly disconnected. It gives me the option to ignore this fact or to eject the share. When I eject the share, things work normally again, meaning that on the next unlock, the mount is called /Volume/Aleph again.

@pbasov

This comment has been minimized.

Copy link

pbasov commented May 5, 2017

Something that I think is worth mentioning is that If you mount the vault by just using Finder, the duplicate isn't created.

@tobihagemann

This comment has been minimized.

Copy link
Member

tobihagemann commented May 5, 2017

For anyone interested in the details: We're using AppleScript to mount the volume, see MacOsXAppleScriptWebDavMounter.java#L53.

Due to the whole refactoring, it's now in webdav-nio-adapter/MacAppleScriptMounter.java#L35, but it's still the same script. Theoretically, we also have a shell script mounter, see webdav-nio-adapter/MacShellScriptMounter.java#L54.

As far as I remember, we have to use AppleScript for OS X >=10.10 because of permission issues. You can't do mkdir in /Volumes anymore.

@tobihagemann

This comment has been minimized.

Copy link
Member

tobihagemann commented Jul 10, 2017

I've let someone check if this issue still persists on macOS 10.13 High Sierra. He didn't see any duplicate folders in /Volumes. I'll wait for more feedback but hopefully this bug is going to be resolved then.

@Wurmdosungen

This comment has been minimized.

Copy link

Wurmdosungen commented Jul 10, 2017

Unfortunately, after days of flawless operation, the problem is now re-occurring for me. After turning on the Mac, I started Cryptomater and unlocked the folder. This lead to the (MacOS) error message "Beim Verbinden mit dem Server „localhost“ ist ein Fehler aufgetreten." (roughly "An error has occurred when connecting to server 'localhost'". After that, Cryptomator showed the folder as unlocked, but there were two empty directories in /Volumes, "CryptomatorFolder" and "CryptomatorFolder-1" ("CryptomatorFolder" being the name of the Cryptomator folder).

Locking and unlocking the folder shows the same result, regardless if I delete both /Volumes folders, or if I keep them. Cryptomator, though, shows the respective folder as unlocked. I am able to manually connect to this folder using the Finder menu "Mit Server verbinden..." ("Connect to server..."). This leads to the Cryptomator folder being available as /Volumes/CryptomatorFolder-2.

After that, and after locking the Cryptomator folder and exiting Cryptomator, I cannot rmdir /Volumes/CryptomatorFolder-2 for a while, the error message being "CryptomatorFolder-2: Resource busy". After a minute or so, I can delete the folder, /Volumes now containing no Cryptomator folder at all.

Now comes the interesting part: When I restart Cryptomator and unlock the folder again, this works - but the three folders /Volumes/Cryptomator, /Volumes/Cryptomator-1 and /Volumes/Cryptomator-2 reappear (!), which the former two being empty and /Volumes/Cryptomator-2 being the actual mount point for the Cryptomator folder.

Since it worked so well for a number of days, I take it for granted that, after rebooting, it will continue to work normally for a while, and that this is a very random bug.

@lichtamberg

This comment has been minimized.

Copy link

lichtamberg commented Jul 12, 2017

I can confirm it @Wurmdosungen - I have the same problem with exactly the same naming... This really sucks because I want to mount my ssh keys there - but this doesnt work fine if the mount point is different each time.

Newest MacBook Pro with latest OSX Sierra.

@BarryMode

This comment has been minimized.

Copy link

BarryMode commented Jul 27, 2017

Was about to open a new issue, but found this instead. Here's some images. If it really gets resolved in 10.13, that's good enough for me.

screen shot 2017-07-27 at 10 51 14 am

screen shot 2017-07-27 at 10 51 26 am

@ChristianSiegert

This comment has been minimized.

Copy link

ChristianSiegert commented Sep 12, 2017

As a temporary workaround (tested in macOS 10.12.6): Use Finder to mount your vault. It always mounts the vault in the same directory:

  1. In Cryptomator, lock your vault if it is not locked.
  2. Click on “More Options” and deselect “Mount Drive”.
  3. Unlock your vault.
  4. Copy the webdav URL (click on the down-arrow symbol to show the menu).
  5. In Finder, go to Go > Connect to server (CMD+K), paste the webdav URL and connect.

Finder will use the vault’s drive name specified in Cryptomator. You can change this name in Cryptomator by checking “Mount Drive”, then edit the drive name, and uncheck “Mount Drive” again.

If you know how to mount webdav via shell, let me know. Haven’t gotten it to work with mount_webdav.

@jdphog

This comment has been minimized.

Copy link

jdphog commented Oct 17, 2017

Is this confirmed to be fixed in High Sierra? I don't have any other reason to upgrade at this point.
Thanks.

@overheadhunter

This comment has been minimized.

Copy link
Member

overheadhunter commented Oct 17, 2017

@jdphog Apparently it is, but beware of #579!

@BarryMode

This comment has been minimized.

Copy link

BarryMode commented Oct 17, 2017

Confirmed. This is fixed in High Sierra.

@lichtamberg

This comment has been minimized.

Copy link

lichtamberg commented Dec 3, 2017

Strange thing is that this doesn't happen anymore on OSX Sierra (occured several times before (nearly each time) - and now it works without problems).

@tobihagemann tobihagemann reopened this Dec 4, 2017

@tobihagemann tobihagemann changed the title Duplicate folders in /Volumes upon unlocking vault Duplicate folders in /Volumes upon unlocking vault in macOS 10.12 Sierra Dec 4, 2017

@kostex

This comment has been minimized.

Copy link

kostex commented Mar 9, 2018

I don't want to be a party pooper, but installed the software on Sierra for the first time (Coming from Boxcryptor Classic)
But I get those pesky dual /Volumes/... entries

I've noticed that when mounting the -1 appeared behind the name, so I've immediately went to /Volumes and indeed found two.. Searched the internet and it brought me here..

Anything I can do about it?
Thanks
ps. the webdav URL connection thing works of course.. but who wants to do that ;-)

@BarryMode

This comment has been minimized.

Copy link

BarryMode commented Mar 9, 2018

@kostex As far as I know, it was never fixed for Sierra, but it doesn't happen on High Sierra.

ustasb added a commit to ustasb/dotfiles that referenced this issue Mar 29, 2018

ustasb added a commit to ustasb/dotfiles that referenced this issue Mar 29, 2018

ustasb added a commit to ustasb/dotfiles that referenced this issue Mar 29, 2018

@overheadhunter overheadhunter added this to the 1.4.0 milestone Apr 6, 2018

@overheadhunter

This comment has been minimized.

Copy link
Member

overheadhunter commented Apr 6, 2018

Today we released our first beta of 1.4.0, which brings FUSE support to macOS and Linux.

Please retest this issue with FUSE enabled and report your findings in this thread.


If you experience any new issues, please report them and tell us what software version (including macOS version, involved applications, etc) you're using.

⚠️ This is a beta version! Make backups and don't use this version for production data. ⚠️

@no-response

This comment has been minimized.

Copy link

no-response bot commented Jun 17, 2018

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment