Gslapt from the menu does not seem to work. I have to su to root in a terminal and type gslapt and then Gslapt loads. I can't get the VL7 testing repo added to the Gslapt sources. It says there is no such place. Also, in order to set up CUPS I had to start from a browser (http://localhost:631/printers); it didn't work from VASM.--GrannyGeek

Gslapt from the menu does not seem to work. I have to su to root in a terminal and type gslapt and then Gslapt loads. I can't get the VL7 testing repo added to the Gslapt sources. It says there is no such place. Also, in order to set up CUPS I had to start from a browser (http://localhost:631/printers); it didn't work from VASM.--GrannyGeek

Sorry, but there is no VL7.0 testing repo - it is simply a collection of files in roughly the same places as they would be under VL6.0. Trouble is, with the switch to .txz packages (which follows current Slackware practice), the repo tools are no longer functional. The original versions needed a specific version of tar to work with lzma compression, the new ones will need not only that, but also a copy of the xz package. Not sure what is needed to get that done.

As to Gslapt, there are two packages up there. If you download this one:

it has a corrected /usr/share/applications/gslapt.desktop. The original had the same problem that the original VL6.0 release of Gslapt had - the .desktop calls gslapt directly, which will not work, since it requires root access. My build simply fixes the .desktop file.

//hda/music on /mnt/amahi type cifs (rw,mand)What I have done in the past is use Thunar to change read/write permissions for the 'amahi' directory, and selected recursive when applying the permissions. However, if I do that under VL7.0, the permissions change straight back to read only for anyone other than root. I have no idea why the permissions won't change, and it means that I can only write to the share as root, which causes problems if I try and access the files from another machine. Problem didn't exist under VL6.0, but I've yet to find a way to fix it with VL7.0.

For general information, Amahi is based on Fedora 12, and the install I'm using is a full Fedora install with Amahi added during the install.

Hmm. I thought I might be able to get round the problem by adding the test share to /etc/fstab, with 'users' specified. Trouble is, it doesn't get that far. I get this error:

Just to say I'm really excited about this. Once I'm finished with writing my MA thesis (in VL6 Light), I'll have enough time at hands to build this or that and contribute stupid questions . I hope there'll be a VL7 Light as well?

This mount.cifs program has been built with the ability to run as a setuid root program disabled. mount.cifs has not been well audited for security holes. Therefore the Samba team does not recommend installing it as a setuid root program.Obviously this is a security concern and they chose to close that door.

mount -t cifs -o username=something -o users //ip_address/share /path/to/mountOf course, this requires root access. Some of the options available to regular users are fusesmb or smbnetfs. I have not tried these, as I prefer KDE's built-in samba handling.

This mount.cifs program has been built with the ability to run as a setuid root program disabled. mount.cifs has not been well audited for security holes. Therefore the Samba team does not recommend installing it as a setuid root program.Obviously this is a security concern and they chose to close that door.

mount -t cifs -o username=something -o users //ip_address/share /path/to/mountOf course, this requires root access. Some of the options available to regular users are fusesmb or smbnetfs. I have not tried these, as I prefer KDE's built-in samba handling.

//hda/movies /home/tooth/smb cifs noauto,users,rw,user=xxxx,password=yyyy 0 0( username and password have been changed....). Under VL6.0, that works fine, though, as you say, root access is needed to perform the mount command.

//hda/movies /home/notme2/Music cifs noauto,users,rw,user=xxxx,password=yyyy 0 0With root access, the command completes sucessfully, and the share is mounted. However, I still have no write access to the share as a normal user. As root, I can write to it, but, even with the 'users' specified (and even though an identical command works in VL6.0), under VL7.0, no joy....

I don't know what the problem is, but there certainly seems to be a problem.....

I also like the KDE handling of Samba shares. Trouble is, I hate KDE. I've also been forced to give up using fusesmb - I was having time out problems on large files, though that may be related to the horrible performance of my Icy Box NAS - I may try it again with the Amahi box, see if it works any better.

\\HDA ibmpeers.net\\HDA\HL-5050-series Brother HL-5050 series\\HDA\print$ \\HDA\Books Books\\HDA\Pictures Pictures\\HDA\Movies Movies\\HDA\Music Music\\HDA\Docs Docs\\HDA\IPC$ IPC Service (ibmpeers.net)And, as I said, the first sample, run under VL6.0 works correctly, and gives the normal user read/write access to the share. When mount is executed under VL7.0, it mouts correctly, but the normal user doesn't have write access, only read access. Root does have read/write access. Which is very strange....