The following bug has been experienced useing the nautilus share extension, which relys on the "net usershare" command: When e.g. deleting (or renaming, moving) a folder that has been shared (via contextmenu) the share definition in /var/lib/usershares won't be deleted (or modified in case of renaming, moving). This causes obsolent share definitions, which may cause the sharing icon of all shared folders to disappear, if the result of "net usershare info" ends with an error message, which is the case whenever the alphabetically last share definitions is obsolent/corrupt. (Exception seems to be shares that begin with the letter "a". Shares that begin with "a" are always listed last) This Bug affects all Distributions using "net usershare" (testet on Ubuntu 10.04 and Ubuntu 12.04 beta-2 as well as the current Debian stable release.) This is a possible security problem: The obsolent share definitions has to be removed, because creating a new folder with the same name of a once shared (and then deleted) folder will unintentionally share the new folder as well. Furthermore it is important that the sharing icons won't disappear, so user will still see that a folder is shared. Both problems can lead to security risks and since the bug affects probably all distributions who use nautilus, the problem is major.
What is Samba supposed to do here? The only thing we can do is to ignore those usershares that have no direcories behind them. We have code for that, so those orphaned usershares should never show up in a share listing. Even if we deleted those usershare files that are invalid in this sense, this will not catch the race condition you mention. We have no way to find out whether the usershare definition matches the directory that the user intended to share. I'm closing this as invalid as seen from the Samba side. Please re-open if you have a solid suggestion how to fix this properly.
>> What is Samba supposed to do here? The only thing we can do is to ignore those >> usershares that have no direcories behind them. We have code for that, so those >> orphaned usershares should never show up in a share listing. The problem of the disappearing sharing icons is going to be fixed, did I get that right? >> Even if we deleted those usershare files that are invalid in this sense, this >> will not catch the race condition you mention. We have no way to find out >> whether the usershare definition matches the directory that the user intended >> to share. When starting nautilus, the usershare command notices the invalid directory and therefore responds with the error message. Instead of just ignoring the error, the share definition should be deleted. This would solve the issue after reboot (which would help in most cases). Of cause it doesn't solve the bug itself, but I think it would be the best workaround. Idea for a final solution: Instead of just defining the path of the shared folder, there could be something aside which would define the share definition as unique. For example the creation date. So even if I share a folder and delete it afterwards, I could make a new folder with the same name which would not be shared automatically. After rebooting the obsolent share definition will be deleted.
Please provide exact steps with just the net usershare and other file system commands (no nautilus magic please) to recreate the problem.
Creating usershares: gnomeuser@gnomeuser:~/Desktop/test$ mkdir /home/gnomeuser/Desktop/test/{bb,gg,pp} gnomeuser@gnomeuser:~/Desktop/test$ net usershare add cc '/home/gnomeuser/Desktop/test/bb' gnomeuser@gnomeuser:~/Desktop/test$ net usershare info [cc] path=/home/gnomeuser/Desktop/test/bb comment= usershare_acl=Everyone:R, guest_ok=n gnomeuser@gnomeuser:~/Desktop/test$ net usershare add ww '/home/gnomeuser/Desktop/test/gg' gnomeuser@gnomeuser:~/Desktop/test$ net usershare add ff '/home/gnomeuser/Desktop/test/pp' gnomeuser@gnomeuser:~/Desktop/test$ net usershare info [ff] path=/home/gnomeuser/Desktop/test/pp comment= usershare_acl=Everyone:R, guest_ok=n [cc] path=/home/gnomeuser/Desktop/test/bb comment= usershare_acl=Everyone:R, guest_ok=n [ww] path=/home/gnomeuser/Desktop/test/gg comment= usershare_acl=Everyone:R, guest_ok=n When creating usershares like this (via terminal), the sharing icons won't appear until nautilus is restarted (respectively a specific command, which I don't know, is executed) gnomeuser@gnomeuser:~/Desktop/test$ ls bb gg pp gnomeuser@gnomeuser:~/Desktop/test$ mv gg ggg gnomeuser@gnomeuser:~/Desktop/test$ ls bb ggg pp gnomeuser@gnomeuser:~/Desktop/test$ net usershare info [ff] path=/home/gnomeuser/Desktop/test/pp comment= usershare_acl=Everyone:R, guest_ok=n [cc] path=/home/gnomeuser/Desktop/test/bb comment= usershare_acl=Everyone:R, guest_ok=n info_fn: file /var/lib/samba/usershares/ww is not a well formed usershare file. info_fn: Error was Path is not a directory. After restarting nautilus, all sharing icons will disappear. The sharing definition is still there: gnomeuser@gnomeuser:/var/lib/samba/usershares$ cat ww #VERSION 2 path=/home/gnomeuser/Desktop/test/gg comment= usershare_acl=S-1-1-0:R guest_ok=n
I don't know how this is related, but; When sharing one of the default folders in the home directory (which all have special icons from the beginning), the sharing icon of only the specific shares folder will also disappear after restarting nautilus. All other shared folders will keep their sharing icons in this case. This does not affect shared folders with normal emblem icons.
Ok. This is a nautilus problem. The last step printing the error message prints that error to stderr, the valid shares are listed on stdout. Again, I think Samba just behaves correctly. Just tested this. Regarding the disappearing icons: Samba does print out a list of the remaining valid shares. Why nautilus does not display them is up to nautilus. I also tested smbclient -L against the different situations: smbd lists the valid shares even when there are invalid ones. Regarding the second point with uniqueness of directories: Yes, we could narrow the race a bit, but we can not close it completely. Inodes can be re-used and most systems don't have an inode birthtime. Closing as invalid again, there is nothing we can do here.