> 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?
yeah, everything worked before. the first time I tried using Samba to
share vfat, I had a little trouble with workstations giving errors about
not being able to set permissions and users. I just added the "create
mask = 777" and "directory mask = 777" lines and everything worked the
same as it did with a Windows share.
now, for whatever reason, the same exact files don't work... I hope I
can figure it out, because I'm sure I'm not the only person interested
in sharing vfat, since it is quite useful to have both Windows and Linux
on a server...
> Not sure what changed. I still haven't dug unto my samba shares yet.
> Someone told me the quit working.
Me either...
> Then use them. You should not need rot once trhe system is setup.
Daily
> usage only needs use access.
> 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.
I once tried "chmod 777 / -R", and I ended up with a system where
everything was accessible by everyone... then I discovered that most of
the internal stuff does not like when its mode is changed, and the
system didn't boot 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
sounds like a lot of work, then I adjust my settings in, say,
/etc/modules.conf, then do the whole thing over again? I'm okay with
doing a bunch of extra typing if I have to, but how 'bout everyone else
in the house? I'd rather just browse to it in Nautilus, double click
it, and modify it. I would love it if it put up a login screen whenever
I double-clicked a file I didn't have permissions to, but it doesn't.
I might be more satisfied if I make an extra set of icons, like
"Nautilus as Root" or "Terminal as Root". (I remember there was a way
to do that. In fact, I did that once, but now I don't remember. It
definitely wasn't sudo. I think it was su.)
> 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.
really? they don't need to write to system directories, like /bin or
/usr/lib? what about when installing, modifying, or updating GATOS or
AIM native?
when I ran my system as user, I made it a habit to go into terminal, su
to root, and run nautilus to do everything, 'cause I hated getting part
way through, then having to start over as root or jump into another
terminal, find my way to the directory I was in, and chmod a couple
times...especially when I couldn't just chmod the whole directory
(because not all modes were the same), and I had to pick files one at a
time to chmod... in fact, without even seeing my example, my little
brother started doing the same thing, just su to root, then run
nautilus...
> I though pam fixed that. Doesn't the console user have permission to
> write to /dev/sgX for CDR access?
hmm, you might be right about that in Shrike. I haven't yet run Shrike
as a user, so I didn't notice...
> 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.
yeah, I do want users installing software all over the place. all our
data is secure, and we always have extra RedHat discs around. the fact
is that we have never caused any problems by running around as root that
we would not have caused anyway by su-ing to root. when we want to
install software, change settings, or otherwise screw with the system,
we will. either we have to su to do it, or we stay logged in as root...
I have a customer bringing me his computer for the third time today. he
keeps trying to "clear space" by deleting stuff (like command.com) from
his main directory on his Windows system. I would set that guy up as a
user, but we all here are disciplined enough to know that if we didn't
put a file there, then we shouldn't take the file out. plus, we know
that our personal data and everything we want to keep should be put in a
single place (like /home/user or /root). our computers don't need any
extra protection from users. well, actually, our computers do need
extra protection from users, but it's not gonna get it, because we will
just keep using su if we need to. if we want a guest to use the
computer, maybe a child who may cause problems, then we just log out and
log in as a user...
> 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.
I beg to differ. I don't think that giving root access defeats that
completely. ("that", being "global file ownership") I see giving root
access as solving that completely...
as far as setting group permissions, that works in FreeBSD, but not any
Linux that I've seen. in FreeBSD, I can just add a user to wheel. when
I try chown-ing to give the group "user" access to system files,
sometimes the system refuses to use the file, saying that it's not the
original. this usually results in a system that doesn't boot...
> 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.
here, we have about 16 computers...more than enough for each person to
have his own computer. besides, don't you think there are people in the
world that live alone?
this is how I would prefer my Linux box...give a user administrative
permission. sudo is a pain to use, and I might as well su if I know the
password. changing modes or owners results in a system that doesn't
boot. therefore, I just use root.
> Won't happen, xcreensaver stores data in $HOME, and runs as nobody.
> You'd have to rebuild xscreensaver to defeatthat protection.
how 'bout if I give "nobody" the /home/nobody folder instead of the /
foler it has now, or how 'bout I make a symlink from the actual
.xscreensaver file (that xscreensaver is running off of) to the root
.xscreensaver file...
> Like this in .xsession
>
> #!/bin/sh
> xhost +localhost
> gnome-session
umm, yeah... where is that file? I expected it to be in ~ like in
other distros, but I can't seem to find it...
> I always us the find command instead if the GUI tool.
hmm, perhaps it's a buggy search tool...
> 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.
yeah. and I think winex released the NPTL capable version the same day
that I said they didn't have it. :-p
