Benjamin Vander Jagt wrote:
As for Samba, I'm about ready to flip! I just set it up in Psyche
(still with the exact same smb.conf file I had that worked fine before),
and now it's not allowing writes to vfat shares, either. I just checked
my permissions on the /sharedc folder, and they were read/write/execute
for root and read/execute for everyone else. In fstab, I switched
"defaults" for "umask=000" (which somehow sets the mask to 777, where
umask=777 sets the mask to 000), and I also updated Samba with up2date. No dice. I set the permissions on the mounted folder on the client
system to 777, no cigar. I added all users to all groups in smbusers. Login was a little different, but still can't write to that one
directory. I have no problem writing to the Ext3 share. Windows
clients can't write to the vfat share, though everyone can write to it
when I start Windows on the server.
So you have a local vfat filesystem you are trying to share using samba?
Interesting. Never tried that. I know vfat doesn't support a lot that samba might want, but you said it worked before, yes?
It's definitely on the server end, but the stupid thing is that
smb.conf, smbusers, smbpasswd, and fstab are all the same. Plus, when I
set it up before, I never had to use smbpasswd -a for anyone, since it's
a guest only share. I'm gonna go nuts if I try configuring it anymore. This is a totally fresh install of Psyche, and when I did a totally
fresh install of Psyche on the twin computer next to it and used the
same smb.conf file (except changing filenames), everything worked fine.
Not sure what changed. I still haven't dug unto my samba shares yet. Someone told me the quit working.
I would agree, only use root when needed, never any other time.
I thank you for your input and your help, but I'm getting tired of everyone (and every program) saying not to run as root. I understand the virtues of separating levels of execution (which is what makes the
Then use them. You should not need rot once trhe system is setup. Daily usage only needs use access.
What really gets on my nerves, running as user, is when I am in the middle of something and need to get root access. Like, when I'm in Nautilus and I carefully select a bunch of files that I want to copy. I go to the destination folder and try to paste them, but the paste command doesn't show up. Then I realize that the directory is under someone else's name, so I su and type nautilus from the terminal. I
So the permissions on the destination directory are set worng, or you shouldn't be putting files there. Ask teh owne of that directory to give you write permission.
right click to paste, but it doesn't have the same files on the clipboard, since now it's someone else's clipboard, so now I have to re-open the source folder and start over again.
how about use root to cget write permission #su #chmod a+w /some/directory
copy the files using you nautilus selection The restore the permission settings
# chmod a-w /some/directory # exit
I can kinda deal with that myself, but having to guide family members over the phone "Open a terminal, enter 'su', enter the root password,
Show them how give others permission to access their directories.
full root access is again ovekill. The don't need to write to system directories like /bin or /usr/lib, just each others data directories.
It jsu permission problems.
type nautilus or konqueror..." Wanna burn a CD? Gotta enter that root password.
I though pam fixed that. Doesn't the console user have permission to write to /dev/sgX for CDR access?
Besides that, considering that everyone here is proficient enough to install their own software, they now must type a password every time they want to do anything.
So you want users installing software all over the place? Most system don't want that. Still, how often is that happening? see also
sudo for a better solution, giving individual users the rights to runs certain commands as root without giving them root access.
file ownership and permissions, but I would also like to see global ownership work just as well for systems that need reliability and not
Giving root access defeats that completely.
Also remember a file (currently) has 3 sets of permissions: user, group, and other. Try using groups access to allow all members permissions, but not non members. Root then is only needed to add/remove members from the group, something the sysadmin would do.
Overall, I'm pleased with how well most stuff works using /root instead of /home/user. Most games these days simply give a warning one time that running as root will save settings in the /root directory instead of the /home/user directory.
So whos setting are saved in /root? Yours, or another users?
Saving per user data is helpfull. It let me save my state, seperate from someone elses, like say my sons. If I always used roo, his data would over write mine, not good.
scripts I tried piggybacking into! (Now to get xscreensaver to write to root's .xscreensaver file instead of nobody's.) Only one hickup...it
Won't happen, xcreensaver stores data in $HOME, and runs as nobody. You'd have to rebuild xscreensaver to defeatthat protection.
adds localhost every time I open a terminal. I can live with that. :-p
Perhaps if I can find the .xsession equivalent, I can have it run xhost +localhost right before opening the window manager.
Like this in .xsession
#!/bin/sh xhost +localhost gnome-session
".xscreensaver" in "/root", and it doesn't find it. Does it absolutely refuse to find hidden files? That can't be the case. When I search for ".xscreensaver" in "/", I get one match...the .xscreensaver file in /slackware/root.
I always us the find command instead if the GUI tool.
Besides, I wanna play Transgaming WineX compatible games. ;-D Apparently they haven't introduced the --with-nptl option. (This brings
up a few questions. Anyone know, is it because Wine is now Lesser GPL? Is Wine's LGPL why Shrike doesn't have it? Or was --with-nptl not
available soon enough?)
wine is just starting to get NTPL fixes. The liscense is not a problem.
Red Hat my not want to support it either, both it was removed mainly because Red Hat didn't have the time to get it working and neither did the wine developers.
-Thomas
