Version: 4.0.80 (using Devel) Installed from: Compiled sources OS: Linux This bug is simmilar: http://bugs.kde.org/show_bug.cgi?id=162805 I manually mount CIFS directories: mount -t cifs -o username=user,password=pass,dir_mode=0777,file_mode=0777,rw //Arquivos/Arquivos /mnt/S I go to Dolphin (KDE 4.1 SVN), when I access this directory I can browse while in icon view. If I put details view Konqueror crashes or goes freeze. But with Dolphin the problem is worse! Dolphin crashes more fast and my other applications stay very slow. I work with samba shares and It's impossible use my network because this.
I would like to confirm this bug. I am running . This bug has been active for all KDE 4 releases I have used. I can confirm that, when a samba share is mounted (I use fstab), and dolphin/konqueror is used to browse this share, icon view browsing is fine, but where "column" or "detail" views are used, the browser will lock up. Other dolphin windows are also locked. INFORMATION: O/S: linux - ubuntu distribution Version: KDE 4.1 beta 2 (4.083) (bug seen in all used prev versions 4.0+). KDE source: ubuntu packages FSTAB exerpt: < //192.168.2.3/alldrv /mnt/server smbfs guest,fmask=666,dmask=777 0 0 >
This is a duplicate of bug #156759, which has more detail on cause and workarounds.
I can confirm this kind of behavior. When I try to change the icon of a folder in a cifs mounted filesystem, dolphin gets stuch excerpt of my fstab //192.168.178.1/ExternalHDD-0-1 /home/claudio/places/fritz cifs rw,mand,noexec,nosuid,nodev,user,guest 0 0 There is a lock on the edited file that is not dying... lsof ... /home/claudio/places/fritz/Library/.directory.lock.tZ7252 ...
I have the same issue with both konqueror and dolphin when loking through image folders. Whenvever you check the preview button in either application, the app. locks up completely. The only way I have found to get it to continue and work (other than killing) is to delete the .directory.lock file from the command line. This allows both konqueror and dolphin to operate perfectly for this directory. Removing the file from the command line sometimes takes a few attempts but as soon as removed the browser immediately springs into life. The issue returns for this directory the next time you navigate to it. A copied version of the same folder structures (kept locally as a backup) works without issue. Hope this information helps to solve this issue. P.S. in icon view the previews on the sidebar work perfectly.
*** This bug has been marked as a duplicate of 156759 ***