I think I'm close to having my dev environment set up exactly the way I want, but one final snag remains. I'm running VirtualBox on a Windows 7 x64 host, with my dev enviroment inside a Ubuntu 12.04 guest. I want to keep the files for my projects on the host filesystem – partly so I can access them when the Ubuntu guest is not running, but also so I can use Tortoise and other Windows based tools (cough Photoshop), and it also eases my backup scheme somewhat.
So I've got a folder "Rails" on my NTFS drive, which I've shared from the host with a user specifically created for the Ubuntu guest. The mount point has been set up and an entry added to fstab (cifs), using a credentials file and the options iocharset=utf8,file_mode=0777,dir_mode=0777
This mounts fine and my Ubuntu user has both read and write permissions to the contents, but when I try to start my Rails app I get permission errors on any files the app needs to write to (e.g. the log file). What gives?
Best Answer
Turns out I was simply looking in the wrong place - I had forgotten that the account on the Windows host needed to have correct access permissions set on the shared folder; it only had
Read & execute
,Write
andList folder contents
. Doh! AddingModify
fixed the problem. So nothing but a silly mistake - but I also learned a bit more about the cifs syntax andfstab
and figured out how to mount as a humble user, allowing the mount points to be in my/home/user
folder. The final mount string in my fstab looks like this (my values replaced with [tokens]):So you only need to set
uid
andgid
to the user and group that you want to own the files on the share after mounting - no need for anything else. I also put the Windows user credentials needed in a separate file under my .config dir and didchmod 400
to stop others from reading it.It took a surprisingly long time to figure all this out as there are a million arguments to use with cifs, and many seem to have misunderstood them - so many people recommend using
file_mode
/dir_mode
777 (which sounds like a really bad idea to me), and pepper with unnecessary arguments likenounix
,noperm
,rw
,iocharset
andnoacl
- none of which are needed to make this work. So while my problem was caused by a simple mistake I'll leave the question (and this answer) here; hopefully someone will find it helpful!Edit: Due to a bug in Samba's cifs implementation it is necessary to add the
nobrl
option as well if you intend to run SQLite databases on the share. Basically, the current Samba cifs Linux client cannot handle the way SQLite locks the database file. Not a great solution, and almost certainly a bad idea in a multi user environment but since in my case it's a single user share, and hosted on the same machine as the client (which should all but eliminate network latency), I'm gonna roll with it.The fstab entry now looks like this: