You are not logged in.
Pages: 1
I am having a rather odd experience with Thunar's access of an autofs created cifs mount point.
I'm using Xubuntu 14.04 where autofs is at 5.0.7-3 - thunar is at 1.6.3-1 - XFCE is at 4.10.
This is my auto.master entry for samba shares:
/mnt/Samba /etc/auto.sambashares --timeout=30 --ghost
And this is my auto.sambashares:
VGORTC13-Public -fstype=cifs,rw,uid=1000,guest,iocharset=utf8 ://VGORT-LMCIN13RC.local/Public
Here is what I CAN do:
I can access the mount point and the remote share through any application I choose and I have read / write access just as expected. I can access the mount point directly from say the XFE file manager and it also does as expected:
sudo automount -vf
Starting automounter version 5.0.7, master map /etc/auto.master
using kernel protocol version 5.02
mounted indirect on /mnt/Samba with timeout 30, freq 8 seconds
ghosting enabled
attempting to mount entry /mnt/Samba/VGORTC13-Public
mounted /mnt/Samba/VGORTC13-Public
Everything works. I can read, edit, and add a new file just as expected.
This is what happens when I access the mount point in Thunar - after I allowed the mount to expire:
attempting to mount entry /mnt/Samba/.hidden
key ".hidden" not found in map source(s).
failed to mount /mnt/Samba/.hidden
attempting to mount entry /mnt/Samba/VGORTC13-Public
mounted /mnt/Samba/VGORTC13-Public
Now here is the dilemma:
** The VGORTC13-Public share is in fact mounted.
** I have full read access to all it's contents.
** I can access and edit a random file and save it back to the share.
** What I cannot do is add a new file to the share though Thunar.
Unless I do one of three things:
(1) Access the share another way like doing an ls -al on the mount point or access it through xfe or whatever. Then I have to close thunar and open it again and now I can add a new file.
(2) Access it once with thunar, close thunar, open it up again, and access the mount point.
(3) Use thunar as root - in my case with a "gksu thunar"
I realize this is an obscure issue since there aren't many autofs users left in the wild but I'm hoping the "key ".hidden" not found in map source(s)" error is some sort of thunar or xfce related situation that other's may have had in the past.
Last edited by Morbius1 (2014-07-05 12:22:50)
Offline
Hi morbius1.
I also run autofs on Xubuntu 14.04 (note that if you are running OOB Xubuntu, you are running Xfce version 4.11) and have noticed this issue.
There is an existing bug report that looks like it may be relevant for this issue that hasn't been addressed yet. Looks like it also affects nautilus, so its probably not a Thunar issue per se (though I don't have a system with nautilus to check).
Now that ubuntu is moving to systemd, I've also tried using the systemd method of automounting "comment=systemd.automount" in /etc/fstab, but I can't get it to work:
CIFS: Unknown mount option "comment=systemd.automount"
...perhaps its not fully supported yet.
Its odd though that restarting Thunar gets it work properly. I think I'll create a bug report for it anyway on Xfce's bug tracker.
EDIT: Bug report created: https://bugzilla.xfce.org/show_bug.cgi?id=11001
Last edited by ToZ (2014-07-05 14:30:39)
Please remember to mark your thread [SOLVED] to make it easier for others to find
--- How To Ask For Help | FAQ | Developer Wiki | Community | Contribute ---
Offline
Another interesting piece of information...
The:
key ".hidden" not found in map source(s).
failed to mount /mnt/Samba/.hidden
...message only appears when you try to access the share from Thunar (doesn't appear if you access it from the terminal).
Please remember to mark your thread [SOLVED] to make it easier for others to find
--- How To Ask For Help | FAQ | Developer Wiki | Community | Contribute ---
Offline
Thank you for responding since I thought I was losing my mind.
...message only appears when you try to access the share from Thunar (doesn't appear if you access it from the terminal).
That's what's so odd about this whole thing. You don't get that error if you access it from anywhere but Thunar. Not from the terminal, or another file manager, or firefox, or gedit, or anything I've thrown at it. Only happens with Thunar - unless you run it as root - otherwise it's acting exactly the way it should act.
It's almost as if Thunar isn't getting any or not listening for any feedback from the autofs process to change and refresh it's permissions.
Offline
It's almost as if Thunar isn't getting any or not listening for any feedback from the autofs process to change and refresh it's permissions.
This is what I'm thinking. I also believe it may have something to do with the .hidden functionality that it supports - given the error message we are seeing. But this is glib functionality (see: https://git.gnome.org/browse/glib/commi … 47bf9efdd7)
Please remember to mark your thread [SOLVED] to make it easier for others to find
--- How To Ask For Help | FAQ | Developer Wiki | Community | Contribute ---
Offline
Now that ubuntu is moving to systemd, I've also tried using the systemd method of automounting "comment=systemd.automount" in /etc/fstab, but I can't get it to work:
CIFS: Unknown mount option "comment=systemd.automount"
...perhaps its not fully supported yet.
I have Fedora20-XFCE in a VBox guest for some reason and it appears that "comment=systemd.automount" has been replaced with "x-systemd.automount". I have the following line in it's fstab that seems to work:
//VGORT-LMCIN13RC.local/Public /home/tester1/Samba/VGort/Public cifs guest,uid=1000,noauto,x-systemd.automount 0 0
I can't get that same line to run in Ubuntu but I'm guessing Ubuntu has just as much systemd stuff that's required and Fedora has the full implementation.
Offline
I have an arch install that uses systemd.automount and it works fine. I believe that Ubuntu's implementation of systemd isn't, as you state, as complete as Fedora's or Arch's. The one thing that I've come to realize about systemd.automount is that it doesn't work exactly like autofs, in that it doesn't timeout the share after a period of non-use (or at least in my testing this is what I'm seeing). It does delay the mounting of the share until it is required. I have come across a reference to an x-systemd.device-timeout parameter that I still need to test to see if that unmounts the share when no longer in use.
Please remember to mark your thread [SOLVED] to make it easier for others to find
--- How To Ask For Help | FAQ | Developer Wiki | Community | Contribute ---
Offline
Pages: 1
[ Generated in 0.022 seconds, 8 queries executed - Memory usage: 573.52 KiB (Peak: 590.36 KiB) ]