With me the problem always occurs when in a running connection the
channel is changed. This may happen in a busy neighborhood, if in the
Router (FritzBox 7530) the automatic channel selection (recommended) is
selected. It certainly may happen too if a Repeater is in use.
If I switch of and on
Public bug reported:
when mounting a cifs share by the command line
sudo mount -t cifs //192.168.178.23/Bilder_klein /mnt -o guest,rw
the cifs unix extensions are disabled by default. The mount option `unix` or
`posix` is refused.
The command `mount` shows:
`//192.168.178.23/Bilder_klein on
@ H I Murphy:
This is not a bug but a feature. In SMBv2 and SMBv3 there are no more
share lists, and SMBv1 is disabled by default in samba 4.11. But the
error message is quite misleading!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
In the German UbuntuUsers forum there are several threads concerning
this bug, for instance:
https://forum.ubuntuusers.de/topic/freigaben-im-netzwerk-sind-nicht-
erreichbar/
For some users it happens regularly (like myself), for others it happens
sometimes and with several kinds of files only,
Thanks, Sergio!
After adding your ppa in a newly installed virtual machine with Xubuntu
20.02, all shares of my NAS and my FritzBox were accessible and
browsable via SMB-1 (client max protocol = NT1). I tried with Thunar and
Nautilus (both gtk and therefore using gvfs); all files are displayed
*** This bug is a duplicate of bug 1872476 ***
https://bugs.launchpad.net/bugs/1872476
I have read the explication of Sergio Durigan Junior in bug 1872476 and
I am convinced now that there is a problem in Samba and not in GIO. So I
shall mark this bug as a duplicate of 1872476 now. Thanks,
I tried the update in a virtual machine. It seems to work. The files on
the NAS are no more shown as empty folders even if they are mounted via
GIO. But it is not the same machine where the bug had occurred before,
so I must go on testing to be shure.
--
You received this bug notification
It seems to be the same problem as bug 1872476, but there it seems to
affect samba. I found that samba 4.11.7 alone works fine and that the
bug only occurs if the samba shares are mounted with gio mount.
Therefore I suppose it is a gio bug.
Before installing a patched samba version in my system I
Hi Sergio Durigan jr.,
could you please tell us what has been changed in the samba 4.11.7
package in your PPA. It would be fine if I could know that before
installing your samba version in my system. I am surprised that you
could find the bug in samba and not in GIO/gvfs, for smbclient and
Public bug reported:
If the samba protocol is reduced to SMB-1 (option client max protocol =
NT1 in smb.conf), in all samba shares mounted with gio mount, the
mounting used by file managers like Nautilus or Thunar, ordinary files
are displayed as empty folders and therefore not usable. The
** Information type changed from Private Security to Public
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1664730
Title:
GVFS violating UNIX permissions inside Samba shares
To manage notifications
I hope a patched version will soon be present in the repositories for
all supported Ubuntu versions. I wonder how such an easy thing could
take such a long time!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
In https://wiki.archlinux.org/index.php/talk:NFS#NetworkManager-wait-
online I found a workaround that works for me (ArchLinux has been using
systemd for a long time already):
* create a file /lib/systemd/system/auto_share.service with the following
contents:
Still an issue in 16.04 LTS! :(
This is utterly ridiculous. It's now been *eight years* and system-
config-samba still does not install properly under Ubuntu 16.04 LTS!
@zerofossifuel 's workaround worked on 16.04 too.
--
You received this bug notification because you are a member of Ubuntu
** Also affects: network-manager (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1577885
Title:
120sec delay during shutdown or reboot with still
Unfortunately, the bug seems to be back in Ubuntu 16.04 (Xenial) now,
probably due to changements in the boot and shutdown sequences. See also
[bug 1577885].
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
This bug seems to be quite similar to "[Bug 211631] Network is brought
down before network filesystems are unmounted (CIFS timeout at
shutdown)", fixed in 2013. Has Xenial brought back an old problem?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Yes, it is. And it would be so easy to fix!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1387274
Title:
system-config-samba.py fails to start due to missing /etc/libuser.conf
Utopic
To manage
Public bug reported:
A double click on a network share displayed in a PCManFM window does not
automatically mount a share that had not yet been mounted before.
Instead, an error message ... is not mounted will be displayed. If I
try to mount the same share in a new window or in an new tab
Public bug reported:
When ever I try to play a mp3 file from a samba share mounted via cifs-
vfs (mount.cifs .. or mount -t cifs ...), audacious refuses playing.
Instead, I get the error message: lseek failed: Invalid argument.
Other Players (VLC, Totem and others) work fine with the same file.
The deprecated LanMan authentication is not safe at all. That for it is just a
bad workaround to set
client lanman auth = yes
client ntlmv2 auth = no
I hope there will soon be an other solution for this problem!
--
You received this bug notification because you are a member of Ubuntu
Bugs,
Adding a trailing slash is an easy workaround. But the bug should be
fixed anyhow. Thanks.
--
umount cifs sharemount with user or users in /etc/fstab arguments doesn't work
any more
https://bugs.launchpad.net/bugs/661025
You received this bug notification because you are a member of Ubuntu
The same problem in Ubuntu 10.10, 32bit.
--
umount cifs sharemount with user or users in /etc/fstab arguments doesn't work
any more
https://bugs.launchpad.net/bugs/661025
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs
Public bug reported:
Binary package hint: cifs-utils
Ubuntu 10.01 Maverick Meerkat, 32bit.
In PyNeighborhood umounting cifs shares does not work any more. Perhaps
it is the same in Smb4K. These programs seem to need umount.cifs, which
is o more present in cifs-utils!
** Affects: cifs-utils
I can reproduce it on Lucid and Maverick under the following conditions:
- the network is a WLAN
- the connection is made by Network Manager or WICD
I don't know what the condition net-device-up IFACE!=lo in
/etc/init/nmbd.conf is really needed for. Can it be recommended to leave
it out and to
I can reproduce it on Lucid and Maverick under the following conditions:
- the network is a WLAN
- the connection is made by Network Manager or WICD
I don't know what the condition net-device-up IFACE!=lo in
/etc/init/nmbd.conf is really needed for. Can it be recommended to leave
it out and to
I had already mentioned above: It's not only a network-manager problem
because it is exactly the same with WICD.
--
Network is brought down before network filesystems are unmounted (CIFS timeout
at shutdown)
https://bugs.launchpad.net/bugs/211631
You received this bug notification because you
I had already mentioned above: It's not only a network-manager problem
because it is exactly the same with WICD.
--
Network is brought down before network filesystems are unmounted (CIFS timeout
at shutdown)
https://bugs.launchpad.net/bugs/211631
You received this bug notification because you
I absolutely do agree with Tom and varanasi. This is a serious usability
problem that should be fixed as soon as possible!
--
Network is brought down before network filesystems are unmounted (CIFS timeout
at shutdown)
https://bugs.launchpad.net/bugs/211631
You received this bug notification
I absolutely do agree with Tom and varanasi. This is a serious usability
problem that should be fixed as soon as possible!
--
Network is brought down before network filesystems are unmounted (CIFS timeout
at shutdown)
https://bugs.launchpad.net/bugs/211631
You received this bug notification
Not fixed for wireless network with WICD too !
--
Network is brought down before network filesystems are unmounted (CIFS timeout
at shutdown)
https://bugs.launchpad.net/bugs/211631
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to samba in
Not fixed for wireless network with WICD too !
--
Network is brought down before network filesystems are unmounted (CIFS timeout
at shutdown)
https://bugs.launchpad.net/bugs/211631
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
An other important reason is that gvfs does not support cifs UNIX
Extensions yet.
--
Network is brought down before network filesystems are unmounted (CIFS timeout
at shutdown)
https://bugs.launchpad.net/bugs/211631
You received this bug notification because you are a member of Ubuntu
Server
An other important reason is that gvfs does not support cifs UNIX
Extensions yet.
--
Network is brought down before network filesystems are unmounted (CIFS timeout
at shutdown)
https://bugs.launchpad.net/bugs/211631
You received this bug notification because you are a member of Ubuntu
Bugs,
I installed Gnome Network admin from the repositories in Ubuntu 9.04
Jaunty (final).
It is not possible to save any locations; after entering a location name
and clicking save, the tool always crashes.
--
[Hardy] Unable to save manual network configurations using network-admin
Public bug reported:
Binary package hint: system-tools-backends
In Ubuntu 9.04 (Jaunty Jackalope) the Gnome Network Administration Tool
(German language, installed from the repositories, package gnome-
network-admin) crashes every time I try to change Host Properties.
** Affects:
** Description changed:
Binary package hint: system-tools-backends
In Ubuntu 9.04 (Jaunty Jackalope) the Gnome Network Administration Tool
(German language, installed from the repositories, package gnome-
- network-admin) crashes every time I try to change Host Properties.
+
Thanks for this status update.
As Thuerry Carrez proposed, I tried to avoid system wide CIFS mounts via
fstab by monting my cifs shares manually with mount.cifs ... in my
home folder. The shutdown problem is still the same.
Using GNOME vfs pseudomounts is not a solution for me because the cifs
Thanks for this status update.
As Thuerry Carrez proposed, I tried to avoid system wide CIFS mounts via
fstab by monting my cifs shares manually with mount.cifs ... in my
home folder. The shutdown problem is still the same.
Using GNOME vfs pseudomounts is not a solution for me because the cifs
Obviously it's an issue with VirtualBox. After changing line 415 in the
installation file of the GuestAdditions of VirtualBox 2.1.4 from 1.6 to
1.6.* , everything works fine now.
The problems with VirtualBox 2.0.0 Beta mentionned above seemes to be
quite an other issue.
--
Cannot set resolution
I suppose that the workaround of Alain Keller does only work with the
OSE version. I could not yet make higher resolutions work in the *non
OSE* version 2.1.4 !
I still do get the following error message by installing the
VBoxGuestAdditions in a Jaunty Client:
Warning: unknown version of the X
I have the same problem, but I had never used Network Manager. I always
use WICD.
--
CIFS/SMBFS shares not unmounted before network is shut down
https://bugs.launchpad.net/bugs/211631
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to samba
I have the same problem, but I had never used Network Manager. I always
use WICD.
--
CIFS/SMBFS shares not unmounted before network is shut down
https://bugs.launchpad.net/bugs/211631
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
I wonder why this bug is still set invalid in gvfs.
I explaned that you misunderstood what I was doing. I never had tried to
share a file that's already been shared! I only tried to copy the folder
dav://gu...@192.168.1.100:53811/Musik to my home folder. That did not
work, the folder was not
Well, English not beeing my native language, I certainly did not explain
very well. Sorry.
The problem is not at all sharing a foreign share. It is a client
problem.
On the client, the shares are published with the syntax dav://. If
you simply try to copy one of the shared folders to the
I am so sorry. I don't know how to explain what I really mean. The
problem is not half as complicated as what you describe, it is very
simple. I never tried to share a file that's already been shared. I
totally agree with you that this is nonsense!
In the folder Public (or Öffentlich, for it's a
** Also affects: gnome-vfs
Importance: Undecided
Status: New
** Also affects: gvfs
Importance: Undecided
Status: New
--
can't copy or move folders with gnome-user-share
https://bugs.launchpad.net/bugs/310598
You received this bug notification because you are a member of
This might be a bug in the backend of WebDAV in gvfs.
Accessing the share with the default syntax dav://... all folders can
be found and opened, but not copied or moved. Using the alternate acces
by the hidden folder ~/.gvfs/WebDAV on IP, every folder can be
copied without problems.
I can't test
I can confirm this issue. Perhaps it is not a bug but on purpose?
Using mount --bind instead of symlinks works fine.
--
file server doesn't follow symlinks
https://bugs.launchpad.net/bugs/252822
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
~/Öffentlich is the name of the folder ~/Public in german systems.
Sorry!
The bug is there in Hardy (0.22 Oubuntu1) and Intrepid (0.40 Oubuntu1).
--
can't copy or move folders with gnome-user-share
https://bugs.launchpad.net/bugs/310598
You received this bug notification because you are a
Public bug reported:
Binary package hint: gnome-user-share
I can share the folder ~/Öffentlich with gnome user share, but when I
try to copy a folder from there to a client, I get the error message
not found. Copying single files works fine. It is also possible to
upload folders from the client
connect to server - Windows share works fine with credentials
(username and password) in Intrepid (Ubuntu 8.10) now, but it is still
broken in Hardy (Ubuntu 8.04). Please don't forget that Hardy is LTS (!)
and that this major bug must absolutely be fixed in Hardy as well
thatfore!
--
no personal
I was not at home last week. Sorry for not answering sooner.
Thierry Carrez is right; the bug seemes to be fixed now. I have done
nothing else but installing the usual updates, and public shares now do
work in Hardy as well as in Intrepid.
Thanks, Max
--
Public shares not possible in home
I was not at home last week. Sorry for not answering sooner.
Thierry Carrez is right; the bug seemes to be fixed now. I have done
nothing else but installing the usual updates, and public shares now do
work in Hardy as well as in Intrepid.
Thanks, Max
--
Public shares not possible in home
I can't understand that the importance of this bug is still set to low
in samba after such a long time!
--
CIFS/SMBFS shares not unmounted before network is shut down
https://bugs.launchpad.net/bugs/211631
You received this bug notification because you are a member of Ubuntu
Bugs, which is
I am surprised that the status of this bug report is still incomplete.
The bug must be known by the samba crew, because it is fixed in samba
3.2.3 implemented in Intrepid.
What I am asking for is to fix it in Hardy too because Hardy is LTS!
--
Public shares not possible in home folder (Hardy
I am sorry. I never wanted to speak for others. It is my opinion, but it
would be better if I had said nothing at all.
considering scripts existed already and were simply executed at the
wrong stage of the shutdown sequence
Do these scripts really fix the problem? Please read the posting of
I am sorry. I never wanted to speak for others. It is my opinion, but it
would be better if I had said nothing at all.
considering scripts existed already and were simply executed at the
wrong stage of the shutdown sequence
Do these scripts really fix the problem? Please read the posting of
I am afraid the problem is that in this case nobody really feels
responsible. Is it a problem of the shutdown sequence (Ubuntu problem),
of the cifs Kernel module (Linux general) or a Samba bug? Who has got to
fix it?
As long as nobody feels responsible there is not much hope indeed.
--
I am afraid the problem is that in this case nobody really feels
responsible. Is it a problem of the shutdown sequence (Ubuntu problem),
of the cifs Kernel module (Linux general) or a Samba bug? Who has got to
fix it?
As long as nobody feels responsible there is not much hope indeed.
--
@ luchio
We are already waiting for years, and nothing did really happen. It is a
shame.
Even if it is far from being a perfect solution, it is better to propose
a workaround like the script of Scott Severance than to do just nothing.
--
CIFS/SMBFS shares not unmounted before network is shut
@ Mathias Gug
Is that what you did need?
Perhaps that can help you: Public shares inside a directory (in this
case it is /home/farber/) are possible only if the access to the
*whole* directory is allowed for everyone. This is not normal. It should
be enough to allow access to the share. It had
@ luchio
We are already waiting for years, and nothing did really happen. It is a
shame.
Even if it is far from being a perfect solution, it is better to propose
a workaround like the script of Scott Severance than to do just nothing.
--
CIFS/SMBFS shares not unmounted before network is shut
@ Mathias Gug
Is that what you did need?
Perhaps that can help you: Public shares inside a directory (in this
case it is /home/farber/) are possible only if the access to the
*whole* directory is allowed for everyone. This is not normal. It should
be enough to allow access to the share. It had
What do you actually mean by configuration section? The few lines for
the share only or the [global] part also?
[Gemeinsam]
path = /home/farber/Gemeinsam
available = yes
browsable = yes
public = yes
writable = yes
The share is not accessible at all even if /home/farber/Gemeinsam is
set to mode
Public bug reported:
Binary package hint: samba
Folders in my home directory can not be shared with guest access
permission, even if the acces mode is set to 0777. That is the case with
net usershare as well as with shares in /etc/samba/smb.conf. The
automatic adding of permissions in Nautilus
What do you actually mean by configuration section? The few lines for
the share only or the [global] part also?
[Gemeinsam]
path = /home/farber/Gemeinsam
available = yes
browsable = yes
public = yes
writable = yes
The share is not accessible at all even if /home/farber/Gemeinsam is
set to mode
mv /etc/rc0.d/S31umountnfs.sh /etc/rc0.d/S14umountnfs.sh
mv /etc/rc6.d/S31umountnfs.sh /etc/rc6.d/S14umountnfs.sh
This fix is a rather old thing; it had been published more than two
years ago.
I had asked here if this solution was correct and really safe, but I did
not get any answer yet!
mv /etc/rc0.d/S31umountnfs.sh /etc/rc0.d/S14umountnfs.sh
mv /etc/rc6.d/S31umountnfs.sh /etc/rc6.d/S14umountnfs.sh
This fix is a rather old thing; it had been published more than two
years ago.
I had asked here if this solution was correct and really safe, but I did
not get any answer yet!
This annoying bug is known for a very long time now. I wonder why
nothing has been done yet!
--
CIFS/SMBFS shares not unmounted before network is shut down
https://bugs.launchpad.net/bugs/211631
You received this bug notification because you are a member of Ubuntu
Server Team, which is
This annoying bug is known for a very long time now. I wonder why
nothing has been done yet!
--
CIFS/SMBFS shares not unmounted before network is shut down
https://bugs.launchpad.net/bugs/211631
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Public bug reported:
Binary package hint: fusesmb
Ubuntu 8.04 Hardy Heron, fusesmb ver. 2.7.2
After creating a new folder or a new file in a share with write
permission via fusesmb, this folder or file can't be renamed by the
client. On the client it disappeares after an error message no such
See also Bug 221387; it might be a duplicate.
--
smb password protected share cannot be accessed
https://bugs.launchpad.net/bugs/206439
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
I can confirm this bug in Hardy-Gnome. If a domain is added to the
hostname in /etc/hosts, sudo does not work any more. In Gutsy that did
not matter; sudo still worked even if a domain name was added:
172.0.0.1 localhost [hostname].[domain]
I think, the problem is not, how the domain name has
I agree with flaccid: This perpetuating and ennoying bug should be fixed
as soon as possible!
That has even become more important with Hardy, since smbfs does not
exist as a workaround any more, smbmount being nothing more than a
wrapper for mount.cifs.
The simple solution proposed in the link
I agree with flaccid: This perpetuating and ennoying bug should be fixed
as soon as possible!
That has even become more important with Hardy, since smbfs does not
exist as a workaround any more, smbmount being nothing more than a
wrapper for mount.cifs.
The simple solution proposed in the link
** Visibility changed to: Public
--
PyNeighborhood shows password for everyone
https://bugs.launchpad.net/bugs/229236
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
Public bug reported:
Binary package hint: nautilus
In Gutsy Connect to server - Windows share still worked fine. Entering
my user name and password I always got write permissions.
In Hardy, when I try to connect to a Windows- or Samba-Share on a Server
in my workgroup using my user name, I am
the syntax of cifs has been adopted for smbfs too, and
that therefore smbfs is mo more able to resolve netbios names (as it
still could in Gutsy) makes a tool like pyNeighborhood very important!
Greetings,
Max-Ulrich Farber
--
in pyNeighborhood only anonymous browsing
https://bugs.launchpad.net
This is a very old and well known problem. See also
http://ubuntuforums.org/showthread.php?t=772774 and
http://ubuntuforums.org/showthread.php?t=293513highlight=cifs+vfs
I wonder why this bug is not fixed yet!
It has been proposed to change S31umountnfs.sh to K14umountnfs.sh in
/etc/rc0.d and
Public bug reported:
After trying to mount a share with sudo mount -t smbfs... using
netbios name in Hardy 8.04, I get the error messages no ip specified,
could nor trsolve name. Using the IP instead of the netbios name does
not work either, I get an error messige Nr. 6 share does not exist.
The
Public bug reported:
Binary package hint: pyneighborhood
Browsing of workgroups only works by anonymous access. As soon as a user
name and password is specified, workgroup browsing fails. Only browsing
of the workgroups is concerned. After entering manually the name and ip
of the server,
Perhaps I have found the explanation:
Does the old smbfs file system not exist any more in Hardy, and has
'smbfs' now become only a synonym of 'cifs'?
Mounting shares with smbfs, but using the syntax of cifs, does work. It
is even possible to unmount shares that had been mountet with smbfs, by
This is a very old and well known problem. See also
http://ubuntuforums.org/showthread.php?t=772774 and
http://ubuntuforums.org/showthread.php?t=293513highlight=cifs+vfs
I wonder why this bug is not fixed yet!
It has been proposed to change S31umountnfs.sh to K14umountnfs.sh in
/etc/rc0.d and
Public bug reported:
Binary package hint: gvfs
I can't mount a public share with username and password with gvfs in
Hardy. The attempt by connect to server - Windows Share does ask for
password if an username is entered, but the connection is not done
correctly and I can't get write permission.
Public bug reported:
Binary package hint: fusesmb
Ubuntu 7.10 Gutsy, FuseSMB version 0.8.6-1
After installation from Ubuntu Gutsy repositories the command 'sudo
chown -R user ~/.smb' is necessary to make FuseSMB scan the network
correctly without Root permissions. Afterwards the file
I forgot to say that it is the command 'sudo fusesmb mountpoint -o
allow_other' that disturbs the files in ~/.smb; without '-o allow_other' there
is nothing changed at the file '~/.smb/fusesmb.cache', and FuseSMB continues
to work.
The option 'user_allow_other' is set in /etc/fuse.conf.
--
I have replaced the Network Manager by WICD, and there is no such
problem any more. It seems to me that WICD does the same work without
changing anything in /etc/resolv.conf.
There seems to be a problem if the IP of the rooter is written in
resolv.conf as a DNS_server. My rooter takes a very long
I have the same problem when 'unix extensions = yes' is set on the Samba
server side. Server and client are both Ubuntu 7.10 (Gutsy).
If the symlink itself is the share, it can be accessed from the client,
and it is followed correctly on the server. The symbol for the share in
the clients GUI is
I am eperiencing the same issue, but only if the network has been
started in runlevel 5 by Network Manager or Wicd. If the network has
been configured manualy and therefore is started in runlevel 2, there is
no shutdown problem even with cifs mounts.
--
Symlinks for umountnfs / sendsigs wrong:
Ryan Lortie wrote:
Since we have confirmation that this is the root cause of the problem we should
probably upload this one to gutsy...
That would be fine! Thanks!
--
libesd leaks pipe file descriptors
https://bugs.launchpad.net/bugs/183411
You received this bug notification because you are a
If I understand well, this bug appears in Feisty only because esound-
common is installed as default, but esound is not. I suppose that there
are dependencies forbidding esound-common to be removed. Is it a good
workaround for Feisty to install esound as well from the repositories
and to let
Sorry, I mean Gutsy (Ubuntu 7.10) and not Feisty!
--
libesd leaks pipe file descriptors
https://bugs.launchpad.net/bugs/183411
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs mailing list
There is still something that I can't understand: The bug appears in Gutsy
because in Gutsy esound is not installed as default. How can a fix in the
package esound solve a problem that only happenes when just this package is not
installed?
A real fix for this bug can't be done in the package
I looked at the description of esound in the readme file inside esound-
common:
... However, it is part of the GNOME platform (for a little while
longer), so we slavishly continue to maintain it.
There seem to be dependences why esound can't simply be taken out, as it
has been done in Gutsy... I
@ Ryan Lortie:
Sorry, I had not yet read your notice when I posted mine. Now I
understand better, thanks!
--
libesd leaks pipe file descriptors
https://bugs.launchpad.net/bugs/183411
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
@ patbeppo:
I would no be surprised if it was the opposite: This problem and the
shutting down of the frozen system the origin of your file system
inconsistency?
I have not installed any ext2/3 drivers for Windows.
--
Gnome freezes after moving or deleting many files
I know, but could you please tell me how I could get a logfile in this
case? Opening files and not closing them correctly afterwards does not
create any debugfile, even being a bad programming mistake!
--
Gnome freezes after moving or deleting many files
https://bugs.launchpad.net/bugs/164971
There have some new important details been observed since, even if we
could not get a useful logfile yet:
When audio preview is activated, but not working for there is no esound
installed, a new pipe is opened whenever the mouse is moved over a
symbol of a mp3-file (You can see that with lsof -c
It all looks to me as if there were really too many files opened. But
how did they get opened and not closed afterwards?
Till now nobody has confirmed the bug who had not handled mp3-files
before or handled other files in folders with many mp3-files in them. Is
this a coincidence?
--
Gnome
1 - 100 of 121 matches
Mail list logo
