HowTo: Using Gigolo to Mount Remote Samba Shares

[altair4]

HowTo: Using Gigolo to Mount Remote Samba Shares

PLEASE NOTE: Gigolo is a facilitator to access and mount remote shares. It uses the same base gnome back-end client packages as the file manager does so if you're currently having a problem connecting to a remote share, Gigolo isn't going fix that.

STEP 1: Install Gigolo

Code: Select all

sudo apt-get install gigolo

STEP2: Initial configuration

Launch gigolo then go to Edit > Preferences

Interface Tab:
Save window position and geometry
Show status icon in the Notification Area
Start minimized in the Notification Area
Show side panel
Deselect Show auto-connect error messages

Then Close Preferences and select the "View" button:
enable: "Toolbar", "Side Panel", and "Status Icon"

STEP 3: Network Browsing - Because of a perennial bug in the gnome backend of Mint this will probably not work. Use STEP 3a instead

When you open up gigolo click on the Network tab on the side panel and it will eventually show you all your workgroups and all the hosts within those workgroups. Once you find the share you're looking for simply double click to mount it. A dialog box will open asking for the following information:

Service type: Windows Share
Server: It should be auto filled
Share: It should be auto filled
Username: Only required if your remote share requires credentials.

The remote share should be displayed in the right panel of gigolo and double clicking the share will open a file manager so you can access it's contents.

STEP 3a: Connecting Directly to a Specific Machine

You don't have to browse to the remote machine you can connect to it directly by name or ip address:

Gigolo > Actions > Connect > Service Type = Windows Share:

Gigolo-Connect-To-Server.png (21.31 KiB) Viewed 3700 times

To bypass the gnome bug make sure to specify the Server and Share.

Leave domain and user name blank.

STEP 4: Auto Mounting Remote Shares on Boot

First: Set gigolo to start at login.

Menu > System Settings > Startup Applications > + (Add) > Choose Application > gigolo


Second: Once you access the remote share using the method described above in STEP 3, you can set this up to mount the remote share automatically:

In the right side panel of gigolo right click the remote share and select "Create Bookmark"
There you can give it a short bookmark name as well as other authentication information you want to pass to the server on boot. The versatility of this utility comes in when you enable the "Auto-Connect" option. This will do two things:

(1) If the server having the remote share is not up at the time you boot, the "Auto-Connect" option will probe the network at an interval specified by the "Bookmark Auto-Connect Interval" you set in STEP 2 and then mount the share.

(2) The other thing it will do is reconnect to the share if the connection to the server is interrupted for whatever reason.

Note: The Auto Mount will happen at login so there is no need to reboot to see if it works as advertised. Just logout and log in again.

Upon login you should see a mount icon to your share on the Desktop as well as on the left side panel of Nemo:

Gigolo-on-Startup.png (52.12 KiB) Viewed 3700 times

ADDITIONAL BENEFITS

Ubuntu has changed the way services are started and when things are mounted and as a result it has introduced a number of bugs. As it turns out, gigolo can actually work around a couple of them.

BUG 1: fstab is executed before the network is up.

The traditional way of automounting a remote share is to add a line in fstab that will execute on boot. The problem is that because of the changes Ubuntu has made, fstab sometimes executes before the network is up. There used to be a parameter "_netdev" that one could add to the fstab expression but that no longer reliably works. The "Auto-Connect" option in gigolo solves this problem by periodically probing the network and mounting when the share is available on the network.

BUG 2: Shutdown hangs when a remote share is mounted.

If you have a remote share mounted in the traditional manner, shutting down the system hangs because the network is shut down before the mountpoints are unmounted. Gigolo works in userspace. At shutdown the system will logoff the user first and will automatically unmount the remote share before passing to the root level shutdown sequence which shuts down the network.

UPDATE: As pointed out by member jan_goyvaerts below, when using LMDE XFCE:

Then, you may need to add the following lines to your ~/.local/share/applications/defaults.list so that Thunar is used to open folders by gvfs-open:

x-directory/gnome-default-handler=Thunar.desktop
inode/directory=Thunar.desktop
x-directory/normal=Thunar.desktop

[Lantesh]

Thanks for posting this. I have an unRAID server that this should work great with!

[lyricmuse]

Thank you so much for this howto. I have been so frustrated with setting up shares between Windows and Linux. This made it too easy.

[gtr1957]

Pardon me if this is 'drift'. I have been successfully using gigolo to mount a windows share. With Mint 11, however, I am having problems with a windows share mounted by gigolo and Libre Office. I can copy a new file to the share.
eg., echo "something">footest;cp footest ~/.gvfs/sharename/ works just fine. However, if I try to write a new file to sharename from within libre office I get an error:
"LibreOffice3.3 Error saving the document Untitled1: General error. General input/output error"

I can save new files to my nfs mounted shares from libre office, and I can open windows shared files mounted with gigolo, modify them in libre office and then write them back. I just can't write a new file from libre office to a windows share mounted with gigolo.

I don't know if this is a gigolo problem or a lbre office problem. I need to use gigolo with this installation of linux mint 11 because I am running it wireless on a netbook, and using fstab to automount windows (CIFS) shares hangs the system on shutdown.

[gtr1957]

A couple of added comments to my previous post. On the same netbook booting different OS's from other partitions.
1. Fedora 15 with gigolo can save new files to the windows share with LibreOffice. This OS also needs gigolo to prevent a hang with an fstab mount of the CIFS fileshare.
2. Mint 10 with gigolo can save new files to the windows share with OpenOffice (I do not have LibreOffice installed on this OS). Note that Mint 10 does NOT need gigolo because fstab mounts of the CIFS fileshare do not hang on shutdown. I added gigolo and set up a mount of the windows share just to test the write behavior.
3. Finally, note that gigolo is only needed with wireless, when I hook up the netbook 'wired' there never is a problem with the hang on shutdown of an fstab CIFS mount. I don't know why Mint 10 did not have a problem with fstab CIFS mounts while Mint 11 does.

[altair4]

You can probably tell by the delay that I don't have an answer. At least I don't have one that matches all of your symptoms.

I cannot reproduce your problem but at the moment all I have are Linux Samba servers in this mix and not Windows servers. There is an option in a classic ( i.e., fstab ) mount of a remote Windows share that takes care of what I believe is your problem called nobrl. It's academic since you can't use the fstab method on this machine but I don't know of a gvfs-mount equivalent to nobrl.

Sorry, I just don't have an answer at the moment.

[gtr1957]

This is kind of a solution for the LibreOffice write permission problem.
'ln -s .gvfs/<MOUNT NAME> foo'
Then save/write to '~/foo/NEWFILE, works

[jan_goyvaerts]

I had to make an additional step to make it work for xfce - because double clicking on the bookmark had no effect whatsoever.

An extract from http://www.uvena.de/gigolo/help.html

Then, you may need to add the following lines to your ~/.local/share/applications/defaults.list so that Thunar is used to open folders by gvfs-open:

x-directory/gnome-default-handler=Thunar.desktop
inode/directory=Thunar.desktop
x-directory/normal=Thunar.desktop

[altair4]

Sorry about that.

I have a bad habit of assuming that what works in Xubuntu works in LMDE XFCE and it clearly does not. In fact there is no ~/.local/share/applications/defaults.list to add any lines to in Xubuntu. I will add your note to the body of the HowTo.

Forgive my sloppiness.

BTW: I have another HowTo concerning XFCE. I don't want to use you as my personal tester but do you see any problems with that one:
Create Samba Shares Directly from Thunar: http://forums.linuxmint.com/viewtopic.php?f=197&t=88255

[Kiwi_Tim]

I have followed the advice described above to configure Gigolo to automatically connect with a Windows 7 share. I used the same password for the share as for LM11 login. In Seahorse I see 2 enties for the same password, one being for login and one being for the Windows Share folder.

Every time a start Linux Mint I have to enter the login keyring password to connect to the share as it doesnot grab the password automatically.

Is this a Seahorse problem or a Gigolo problem?

I'm a absolute Linux newbie, so please speak in simple terms.

Many thanks,

Tim

[altair4]

I used the same password for the share as for LM11 login. In Seahorse I see 2 enties for the same password, one being for login and one being for the Windows Share folder.

Not an expert on seahorse but the actual Mint user login password is not in seahorse. That may be the seahorse password plus the smb share password but not the login password to your Mint account. I don't think this is a gigolo issue - it's looking for the password in the keyring. It's the keyring itself that's asking for a password.

EDIT: you might want to start a separate topic and explain your situation - that you have an entry in seahorse for your login password. Any posts that have the work "Samba" in the title are usually relegated to the lunatic fringe. You'll get a better answer in the general forum.

[Kiwi_Tim]

My issue above is now understood. Short answer is I need to live with the auto login to share folder not working because I have chosen to auto login LM at boot up.

See here http://forums.linuxmint.com/viewtopic.php?f=90&t=97646

Tim
New Zealand

[dhdurgee]

I am seeing something a little strange and hope someone can point me to what I have overlooked or missed.

I am in the process of migrating a system from LM8 helena to LM13 maya. This system offers a samba shared directory and I have copied the share configuration from helena to maya. I am using gigolo 0.4.1 on a LM11 katya system to mount this share. The gigolo bookmark defines this as a windows share with userid provided.

The share works from katya in both cases, but I am seeing differences that lead me to believe I missed something. If I have helena booted any files copied by the katya system to the share have the user and group set to the userid. If I have maya booted any files copied by the katya system to the share have user "nobody" and group "nogroup", which of course is not what I want.

Did I miss something in setting up maya that would result in guest access instead of access with the provided userid? Looking at the log files helena has samba 3.4.0 while maya has samba 3.6.3 running. Is there a difference between releases that I need to take into account?

Dave

[altair4]

Will need to see what you shared and what samba method you are using to share so please post the output of the following commands:

Code: Select all

testparm -s

Code: Select all

net usershare info --long

[dhdurgee]

Will need to see what you shared and what samba method you are using to share so please post the output of the following commands:

Code: Select all

testparm -s

Code: Select all

net usershare info --long

Per your request the testparm outputs for helena and maya are in the attached zip file. There was no output in response to the net usershare info --long on either system.

Dave

[altair4]

Cheese and Crackers!

I forgot, you're the one with OS/2 in the mix of things in your lan. It will take me a bit to go though that but here's my best guess:

You have a guest accessible share. If you are passing a username and password when you try to access the share Samba will do the following:

** It will try to find a match in the samba password database.

** If there is one then you will access with that user name.

** If it can't find one it uses "map to guest = Bad User" to convert that remote user to the default guest account which is "nobody" and all files will be saved with that user name.

So if you are going to pass credentials for a share that doesn't require it and you need to preserve the remote user's name you need to add that user to the password database:

Code: Select all

sudo smbpasswd -a user-name

[dhdurgee]

That appears to be what I missed. After I ran the smbpasswd command and added the userid I now see the userid/group set when using maya as well as when using helena.

Thanks for your quick assistance in this matter.

Dave

[dhdurgee]

I decided to try installing gigolo on another system and encountered a problem. This system has Linux Mint 13 x64 cinnamon installed. Gigolo appeared to install OK and I was able to create a bookmark and connect it. Unfortunately at a later point I encountered a problem of some kind and the .gvfs directory disappeared! I still have the folder open and can use it from the desktop, but I cannot access the share in the .gvfs tree.

Looking in my /var/log directory I see:

kern.log:
Jul 23 16:25:55 DG41TY kernel: [278441.310830] gvfs-fuse-daemo[1848]: segfault at 8 ip 00007f17cb203b91 sp 00007f17ca0d2b38 error 4 in libc-2.15.so[7f17cb17b000+1b3000]

syslog:
Jul 23 16:25:55 DG41TY kernel: [278441.310830] gvfs-fuse-daemo[1848]: segfault at 8 ip 00007f17cb203b91 sp 00007f17ca0d2b38 error 4 in libc-2.15.so[7f17cb17b000+1b3000]

So for some reason the gvfs-fuse-daemon crashed, which I assume is what took out my .gvfs directory. Can I restart this without a reboot? What caused the problem? How can I avoid this in the future?

Dave

[altair4]

My knowledge of the inner workings of gvfs is limited so I will give you what I know.

It's not clear from your post if the $HOME/.gvfs directory itself disappears or the mounted share at $HOME/.gvfs/share on server disappears. Gigolo should handle the latter issue automatically but if .gvfs itself disappears then somewhere along the way you should have seen a "Transport endpoint is not connected" error.

Run the following command to see if it's mounted:

Code: Select all

mount

You should get something like:

gvfs-fuse-daemon on /home/xxxxx/.gvfs type fuse.gvfs-fuse-daemon

If it is not mounted mount it:

Code: Select all

/usr/lib/gvfs/gvfs-fuse-daemon ~/.gvfs

If it is mounted you can try to unmount it and remount it:

Code: Select all

fusermount -zu ~/.gvfs
/usr/lib/gvfs/gvfs-fuse-daemon ~/.gvfs

The only other thing I can think of is that you switched users and gvfs is confused by who the fuse user actually is at the moment.

[dhdurgee]

My knowledge of the inner workings of gvfs is limited so I will give you what I know.

It's not clear from your post if the $HOME/.gvfs directory itself disappears or the mounted share at $HOME/.gvfs/share on server disappears. Gigolo should handle the latter issue automatically but if .gvfs itself disappears then somewhere along the way you should have seen a "Transport endpoint is not connected" error.

Run the following command to see if it's mounted:

Code: Select all

mount

You should get something like:

gvfs-fuse-daemon on /home/xxxxx/.gvfs type fuse.gvfs-fuse-daemon

If it is not mounted mount it:

Code: Select all

/usr/lib/gvfs/gvfs-fuse-daemon ~/.gvfs

If it is mounted you can try to unmount it and remount it:

Code: Select all

fusermount -zu ~/.gvfs
/usr/lib/gvfs/gvfs-fuse-daemon ~/.gvfs

The only other thing I can think of is that you switched users and gvfs is confused by who the fuse user actually is at the moment.

The $HOME/.gvfs directory itself had disappeared. You are correct, there was an error message that I did not note:

Software caused connection abort(103)
/home/dhdurgee/.gvfs/hdrive on tp600e/VM

Given this I attempted your second option and this did indeed restore the directory. But when I browsed into the share with FCL I got the above error again when I attempted to change into the VM directory! I just tried it again using MC instead and there I don't even see the error message but the same crash occurs. I just tried it again in a terminal window and see similar behavior:

dhdurgee@DG41TY ~ $ cd .gvfs
dhdurgee@DG41TY ~/.gvfs $ ls
hdrive on tp600e
dhdurgee@DG41TY ~/.gvfs $ cd hdrive\ on\ tp600e/
dhdurgee@DG41TY ~/.gvfs/hdrive on tp600e $ ls
bell atlantic IMUX class_V2.ppt downloads.zip manuals My_Pictures os2-apps.zip Temp.zip win-apps.zip
books IMUX_V2.ppt My_Music os2-apps temp VM
dhdurgee@DG41TY ~/.gvfs/hdrive on tp600e $ cd VM
dhdurgee@DG41TY ~/.gvfs/hdrive on tp600e/VM $ ls
ls: reading directory .: Software caused connection abort
dhdurgee@DG41TY ~/.gvfs/hdrive on tp600e/VM $ cd
dhdurgee@DG41TY ~ $

Going back to my /var/log/kern.log I see more errors with these attempts:

Jul 24 08:36:07 DG41TY kernel: [336653.177327] gvfs-fuse-daemo[9727]: segfault at 8 ip 00007f7844522b91 sp 00007f7842bf0b38 error 4 in libc-2.15.so[7f784449a000+1b3000]
Jul 24 08:43:12 DG41TY kernel: [337077.879946] gvfs-fuse-daemo[9797]: segfault at 8 ip 00007fe243365b91 sp 00007fe242234b38 error 4 in libc-2.15.so[7fe2432dd000+1b3000]
Jul 24 08:44:55 DG41TY kernel: [337181.186449] gvfs-fuse-daemo[9885]: segfault at 8 ip 00007f6af4f4bb91 sp 00007f6af3e1ab38 error 4 in libc-2.15.so[7f6af4ec3000+1b3000]

This is going to make gvfs a little hard to use. I was looking at it as on another system I have fewer problems with gvfs than with cifs, but until this can be addressed it looks like I will need to stick with cifs mounts on this system.

Dave