Sven Joachim wrote:
> David Baron wrote:
>
> > Any attempt to chown -R thisuser:thisuser /home/thisuser/.*
Gack! :-(
> > For example,to reset permissions of hidden items, will change ALL
> > users' home folders, everything. Actually, on the surface, this
> >
On 05/07/14 21:56, David Baron wrote:
Continuing to set up my new 64-bit install.
Any attempt to chown -R thisuser:thisuser /home/thisuser/.*
For example,to reset permissions of hidden items, will change ALL users' home
folders, everything. Actually, on the surface, this might seem co
On 2014-07-05 22:56 +0200, David Baron wrote:
> Any attempt to chown -R thisuser:thisuser /home/thisuser/.*
>
> For example,to reset permissions of hidden items, will change ALL users' home
> folders, everything. Actually, on the surface, this might seem correct
> beh
On Sat, 05 Jul 2014 23:56:47 +0300
David Baron wrote:
> Continuing to set up my new 64-bit install.
>
> Any attempt to chown -R thisuser:thisuser /home/thisuser/.*
>
> For example,to reset permissions of hidden items, will change ALL
> users' home folders, everything. A
Continuing to set up my new 64-bit install.
Any attempt to chown -R thisuser:thisuser /home/thisuser/.*
For example,to reset permissions of hidden items, will change ALL users' home
folders, everything. Actually, on the surface, this might seem correct
behavior because of the '.&#x
long
> to the wrong user. I have probably copied stuff from that user's
> account when I first initialized the card. Problem is, it now only
> allows manipulation/copying/deleting from that user's account.
> Trying to chown it as root fails epically. What gives?
What do you
en I first initialized the card. Problem is, it now only
allows manipulation/copying/deleting from that user's account.
Trying to chown it as root fails epically. What gives? How can these
cards have any ownership bits at all? Aren't they all FAT16/Fat32???
Will be greateful for any
Chris Burkhardt wrote:
>> chown chrisj.chrisj ~chrisj
>>
>> That won't follow the .. link.
>
> Shouldn't that include the recursive flag?
>
> chown -R chrisj.chrisj ~chrisj
Apologies, yes it should.
--
Chris Jackson
Shadowcat Systems Ltd.
--
T
Johannes Wiedersich wrote:
> Douglas A. Tutty wrote:
>> I know that I could have used find to look for all files owned by the
>> old UID, plunked it through xargs and chowned them that way, but is
>> there a way, as root, to chown directly the hidden files without
>
Chris Jackson wrote:
> Douglas A. Tutty wrote:
>
>> I know that I could have used find to look for all files owned by the
>> old UID, plunked it through xargs and chowned them that way, but is
>> there a way, as root, to chown directly the hidden files without
&
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Douglas A. Tutty wrote:
> I know that I could have used find to look for all files owned by the
> old UID, plunked it through xargs and chowned them that way, but is
> there a way, as root, to chown directly the hidden files without
>
Douglas A. Tutty wrote:
[...]
> I know that I could have used find to look for all files owned by the
> old UID, plunked it through xargs and chowned them that way, but is
> there a way, as root, to chown directly the hidden files without
> chowning the whole box?
>
> Just for m
Douglas A. Tutty wrote:
Hello all,
I have a really basic question; I really messed up my box.
I was doing a reinstall on an old box after a drive failure. I restored
/home but one of the UIDs were created differently so I needed to chown
their directory, including all the hidden files in
Douglas A. Tutty wrote:
I know that I could have used find to look for all files owned by the
old UID, plunked it through xargs and chowned them that way, but is
there a way, as root, to chown directly the hidden files without
chowning the whole box?
The simplest way would be to recursively
Hello all,
I have a really basic question; I really messed up my box.
I was doing a reinstall on an old box after a drive failure. I restored
/home but one of the UIDs were created differently so I needed to chown
their directory, including all the hidden files in their ~/.
Without thinking
On Wed, 10 Dec 2008 08:46:49 +
Tzafrir Cohen <[EMAIL PROTECTED]> wrote:
> On Tue, Dec 09, 2008 at 09:29:14PM -0500, Celejar wrote:
>
> > > chown root
> >
> > Harmless unless root chooses to run it (in which case it would be a
> > problem regardless of
On Tue, 2008-12-09 at 22:40 +0100, Christopher Zimmermann wrote:
> Hi!
>
> On my debian box using linux kernel its not possible to give away
> files:
>
> [EMAIL PROTECTED]:~% touch foo
> [EMAIL PROTECTED]:~% chown otheruser foo
> chown: changing ownership of `foo&#
On Tue, Dec 09, 2008 at 10:40:22PM +0100, Christopher Zimmermann wrote:
> On my debian box using linux kernel its not possible to give away files:
>
> [EMAIL PROTECTED]:~% touch foo
> [EMAIL PROTECTED]:~% chown otheruser foo
> chown: changing ownership of `foo': Operation not
On Tue, Dec 09, 2008 at 09:29:14PM -0500, Celejar wrote:
> > chown root
>
> Harmless unless root chooses to run it (in which case it would be a
> problem regardless of which user he chown's it to),
If it is executable and setuid then root didn't have to choose to r
rrible thing to happen, that any one could appropriate
> > > your files to themselves.
> >
> > I've been wondering about this; what would be the problem with the OS
> > allowing user1 to chown his files to user2, assuming we don't allow
> > this to occur with su
en wondering about this; what would be the problem with the OS
> allowing user1 to chown his files to user2, assuming we don't allow
> this to occur with suid executables, of course.
umm
chown root
you could always use sudo with commands limited to chown user2
but
>
> Cel
>>> your files to themselves.
>>
>> I've been wondering about this; what would be the problem with the OS
>> allowing user1 to chown his files to user2, assuming we don't allow
>> this to occur with suid executables, of course.
>
> It would be a DoS a
ing to happen, that any one could appropriate
> >> your files to themselves.
> >
> > I've been wondering about this; what would be the problem with the OS
> > allowing user1 to chown his files to user2, assuming we don't allow
> > this to occur with suid execu
>> behaviour and allow all users to chown their own files?
>
>As others have mentioned, normally this is a bad idea. But if you
>have a specialized need for it, you can write a small program to open
>the file, check the owner with fstat, then change the owner with
>fchown. I
ing to happen, that any one could appropriate
> >> your files to themselves.
> >
> > I've been wondering about this; what would be the problem with the OS
> > allowing user1 to chown his files to user2, assuming we don't allow
> > this to occur with suid executabl
Christopher Zimmermann <[EMAIL PROTECTED]> writes:
> Hi!
>
> On my debian box using linux kernel its not possible to give away files:
>
> [EMAIL PROTECTED]:~% touch foo
> [EMAIL PROTECTED]:~% chown otheruser foo
> chown: changing ownership of `foo': Operation
t this; what would be the problem with the OS
> allowing user1 to chown his files to user2, assuming we don't allow
> this to occur with suid executables, of course.
It would be a DoS against user2 if disk quotas are used.
Sven
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
On Tue, 9 Dec 2008 13:53:47 -0800 (PST)
Arc Roca <[EMAIL PROTECTED]> wrote:
> That would be a terrible thing to happen, that any one could appropriate your
> files to themselves.
I've been wondering about this; what would be the problem with the OS
allowing user1 to chown h
:
From: Christopher Zimmermann <[EMAIL PROTECTED]>
Subject: Unrestrict chown?
To: debian-user@lists.debian.org
Date: Tuesday, December 9, 2008, 4:40 PM
Hi!
On my debian box using linux kernel its not possible to give away files:
[EMAIL PROTECTED]:~% touch foo
[EMAIL PROTECTED]:~% chown otherus
On 2008-12-09 22:40 +0100, Christopher Zimmermann wrote:
> On my debian box using linux kernel its not possible to give away files:
>
> [EMAIL PROTECTED]:~% touch foo
> [EMAIL PROTECTED]:~% chown otheruser foo
> chown: changing ownership of `foo': Operation not permitted
>
Hi!
On my debian box using linux kernel its not possible to give away files:
[EMAIL PROTECTED]:~% touch foo
[EMAIL PROTECTED]:~% chown otheruser foo
chown: changing ownership of `foo': Operation not permitted
only root can change file owners. Is it possible to configure this
behaviour and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dexter Filmore wrote:
> Won't do me good, lots of subdirs where I need to copy selections. Will mount
> on another machine and copy over 100MBit, will have to do. Filed a bug
> report, we'll see.
In the meantime you could have a look at rsync. It ha
Am Mittwoch, 19. November 2008 20:02:33 schrieb Johannes Wiedersich:
> Dexter Filmore wrote:
> > Am Mittwoch, 19. November 2008 09:02:03 schrieb Raj Kiran Grandhi:
> >> Whatever is wrong with good old 'cp'? You can just add a redirect to
> >> /dev/null if the warnings bother you.
> >
> > What's wro
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dexter Filmore wrote:
> Am Mittwoch, 19. November 2008 09:02:03 schrieb Raj Kiran Grandhi:
>> Whatever is wrong with good old 'cp'? You can just add a redirect to
>> /dev/null if the warnings bother you.
>
> What's wrong with the driver working as sup
Am Mittwoch, 19. November 2008 09:02:03 schrieb Raj Kiran Grandhi:
> Dexter Filmore wrote:
> > I use these options to mount an NTFS partition:
> >
> > users,gid=fuse,umask=0002,silent,utf8,locale=de_DE.utf8
> >
> > Now "silent" is supposed to suppress wa
Dexter Filmore wrote:
I use these options to mount an NTFS partition:
users,gid=fuse,umask=0002,silent,utf8,locale=de_DE.utf8
Now "silent" is supposed to suppress warnings on chmod/chown errors, each time
a copy operation is completed I get "couldn't change permissions on
I use these options to mount an NTFS partition:
users,gid=fuse,umask=0002,silent,utf8,locale=de_DE.utf8
Now "silent" is supposed to suppress warnings on chmod/chown errors, each time
a copy operation is completed I get "couldn't change permissions on XY"
I need to c
ives are uid
>500 and gid 500.
>
>Now under Debian the same user name and password I'd previously had
>are uid 1000 and gid 1000. Though I can access the files on the drive
>I can't do anything with them except as root.
>
>How can I rectify this? chown -R 1000:1000?
;d previously had
> >are uid 1000 and gid 1000. Though I can access the files on the drive
> >I can't do anything with them except as root.
> >
> >How can I rectify this? chown -R 1000:1000?
> >
> >This'll cause problems with the lost+found as well as any
I can't do anything with them except as root.
>
>How can I rectify this? chown -R 1000:1000?
>
>This'll cause problems with the lost+found as well as any .Trash
>folders, should I then change the uids and gids back?
chown -R will work, but may be a little too indiscriminat
be owned by root but the group to be users. this didn't get recursively
filtered down.
Now under Debian the same user name and password I'd previously had are uid
1000 and gid 1000. Though I can access the files on the drive I can't do
anything with them except as root.
I can access the files on the drive I can't do
> anything with them except as root.
>
> How can I rectify this? chown -R 1000:1000?
>
> This'll cause problems with the lost+found as well as any .Trash folders,
> should I then change the uids and gids back?
>
I
ould fix the parent system. When done, remove the
> chroot. Here is some reference documentation.
>
> http://www.debian.org/doc/manuals/reference/ch-tips.en.html#s-chroot
You shouldn't have to compare and chown manually...
Once you've installed the chroot (e.g. in /mnt/foobar) then
On Wed, Jun 20, 2007 at 12:17:24AM +, s. keeling wrote:
> Simon <[EMAIL PROTECTED]>:
> > OK.. So i was in my /root/ directory and put just one too many "."s in
>
> By "/root/", do you mean root's $HOME ("~root"), or do you mean root
> of the filesystem, "/"?
That shouldn't matter: The parent
On Tue, Jun 19, 2007 at 06:14:16PM -0600, Bob Proulx wrote:
> Simon wrote:
> > OK.. So i was in my /root/ directory and put just one too many "."s in
> > the line... Now i have a lot of files that i own!!
> >
> > I think the term is "DOH!".
> >
> > Is there any way to fix these?
>
> Personally I
Simon <[EMAIL PROTECTED]>:
> OK.. So i was in my /root/ directory and put just one too many "."s in
By "/root/", do you mean root's $HOME ("~root"), or do you mean root
of the filesystem, "/"?
> the line... Now i have a lot of files that i own!!
--
Any technology distinguishable from magic i
Simon wrote:
> OK.. So i was in my /root/ directory and put just one too many "."s in
> the line... Now i have a lot of files that i own!!
>
> I think the term is "DOH!".
>
> Is there any way to fix these?
Personally I would install a chroot on my system, install in the
chroot all of the package
n the future (no finger pointing, I do similar things all the
time). Something like:
chown -R root:root `pwd`
or
chown -R root:root .
or
chown -R root:root /full/path/ (not quite as fun but infallible).
Good luck!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of &qu
On Wed, Jun 20, 2007 at 09:24:06AM +1200, Simon wrote:
> OK.. So i was in my /root/ directory and put just one too many "."s in
> the line... Now i have a lot of files that i own!!
>
> I think the term is "DOH!".
heh heh. That's pretty good.
SO I don't think this all too much of a problem. Most
OK.. So i was in my /root/ directory and put just one too many "."s in
the line... Now i have a lot of files that i own!!
I think the term is "DOH!".
Is there any way to fix these?
Simon
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PR
Kent West wrote:
> No; someone else mentioned it being in this package, but I was just
> curious about the info not being in "man chown", so I don't need to go
> any further. (And, if it matters, I'm not the OP; I was just making
> comment/question and apparentl
Dave Sherohman writes:
> chown(1) is the command-line program. chown(2) is the underlying system
> call used by chown(1) to do its dirty work, which is relevant here
> because chown(2)'s man page explicitly mentions that it only works for
> priviliged users, but chown(1)'s d
On Tue, Aug 15, 2006 at 09:49:41PM EDT, Dave Sherohman wrote:
> On Tue, Aug 15, 2006 at 03:49:23PM +0100, Clive Menzies wrote:
> > On (15/08/06 09:29), Kent West wrote:
> > > Hmm; on my box:
> > >
> > > [EMAIL PROTECTED]:/home/westk:> man 2 chown
>
John Hasler wrote:
Kent West writes:
Hmm; on my box:
[EMAIL PROTECTED]:/home/westk:> man 2 chown
No manual entry for chown in section 2
Do you have manpages-dev installed?
No; someone else mentioned it being in this package, but I was just
curious about the info not being
On Tue, Aug 15, 2006 at 03:49:23PM +0100, Clive Menzies wrote:
> On (15/08/06 09:29), Kent West wrote:
> > Hmm; on my box:
> >
> > [EMAIL PROTECTED]:/home/westk:> man 2 chown
> > No manual entry for chown in section 2
> > See 'man 7 undocumented'
Kent West writes:
> Hmm; on my box:
> [EMAIL PROTECTED]:/home/westk:> man 2 chown
> No manual entry for chown in section 2
Do you have manpages-dev installed?
--
John Hasler
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>I am user "aluno" and as so, I create a directory in my own $HOME
>
>[EMAIL PROTECTED]:~$ mkdir trash [EMAIL PROTECTED]:~$ ls -ld trash
> drwxr-xr-x 2
>aluno aluno 4096 2006-08-14 23:09 trash
>
>I want the user called "teste" to be the
>Kent wrote:
>I've been unable to find this in the info page for chown. Odd that
>it's
>not documented in the "official" documentation (as I understand
>it). I
>wonder how we're supposed to know this (assuming Paul's not always
>ther
On Tue, Aug 15, 2006 at 09:29:25AM -0500, Kent West wrote:
> [EMAIL PROTECTED]:/home/westk:> man 2 chown
> No manual entry for chown in section 2
> See 'man 7 undocumented' for help when manual pages are not available.
$ dpkg -S /usr/share/man/man2/chown.2.gz
manpages-de
On (15/08/06 09:29), Kent West wrote:
> Hmm; on my box:
>
> [EMAIL PROTECTED]:/home/westk:> man 2 chown
> No manual entry for chown in section 2
> See 'man 7 undocumented' for help when manual pages are not available.
Hi Kent
$ man chown
works here; it seem
Paul Dwerryhouse wrote:
On Tue, Aug 15, 2006 at 07:19:18AM -0500, Kent West wrote:
I've been unable to find this in the info page for chown.
It often helps to look at the documentation for system calls; if I look at
the man page for the chown system call - man 2 chown - whic
On Tue, Aug 15, 2006 at 07:19:18AM -0500, Kent West wrote:
> I've been unable to find this in the info page for chown. Odd that it's
> not documented in the "official" documentation (as I understand it). I
> wonder how we're supposed to know this (assuming Pa
Can someone explain me why he can't ?
>>
>
> Only the root user can change the ownership of a file or directory; use
> su or sudo to change to root first, and then try the same command again.
>
I've been unable to find this in the info page for chown. Odd that
On Tue, Aug 15, 2006 at 12:15:54AM -0200, Gilberto Martins wrote:
>I have a user called "teste"
>I want the user called "teste" to be the owner of this directory
>That means "aluno" cannot do this. Can someone explain me why he can't ?
Only the root user can change the ownership of a f
ld trashdrwxr-xr-x 2 aluno aluno 4096 2006-08-14 23:09 trashI want the user called "teste" to be the owner of this directory[EMAIL PROTECTED]
:~$ chown teste trashchown: mudando permissões de `trash': Operação não permitidaThat means "aluno" cannot do this.Can someone explai
On Thursday 09 March 2006 03:42, Joost Kraaijeveld wrote:
>Hi,
>
>I have a chown problem I do not understand. What is wrong with this
>chown command (and better, what can I do to solve the problem) ?:
>
>panoramix:/home/jkr/MP3# chown -R jkr.jkr *
s/b chown -R jkr:jkr *
>
On Thu, Mar 09, 2006 at 10:40:19AM +0100, Lionel Elie Mamane wrote:
> On Thu, Mar 09, 2006 at 09:42:54AM +0100, Joost Kraaijeveld wrote:
>
> > I have a chown problem I do not understand. What is wrong with this
> > chown command (and better, what can I do to solve the problem) ?
On Thu, 2006-03-09 at 10:40 +0100, Lionel Elie Mamane wrote:
> On Thu, Mar 09, 2006 at 09:42:54AM +0100, Joost Kraaijeveld wrote:
>
> > I have a chown problem I do not understand. What is wrong with this
> > chown command (and better, what can I do to solve the problem) ?:
>
On Thu, Mar 09, 2006 at 09:42:54AM +0100, Joost Kraaijeveld wrote:
> I have a chown problem I do not understand. What is wrong with this
> chown command (and better, what can I do to solve the problem) ?:
> panoramix:/home/jkr/MP3# chown -R jkr.jkr *
> chown: invalid option -- =
Hi Jost,
> I have a chown problem I do not understand. What is wrong with this
> chown command (and better, what can I do to solve the problem) ?:
>
> panoramix:/home/jkr/MP3# chown -R jkr.jkr *
> chown: invalid option -- =
> Try `chown --help' for more information.
&g
Hi,
I have a chown problem I do not understand. What is wrong with this
chown command (and better, what can I do to solve the problem) ?:
panoramix:/home/jkr/MP3# chown -R jkr.jkr *
chown: invalid option -- =
Try `chown --help' for more information.
panoramix:/home/jkr/MP3#
--
Groeten,
Edward Speyer wrote:
Hi!
I'm stuck trying to find a nice way to allow rsync / rdiff-backup enough
permissions to keep ownership information intact at the backup-receiving
end.
I /could/ run as root on the backup-reciever, but it'd be nice if there
was a less sledge-hammer approach to
These are all great suggestions!
My current root-use-avoidance plans were to tar up each filesystem
locally into a tarball owned by some special "backup" user, then rsync
the tarball to another machine (rather than rsyncing the filesystem
itself).
The Mike Rubel page that Clive Menzies mentioned
eserved on the backup host.
>
> Ken
I do the opposite. I let the remote servers log in, using a modified
rsnapshot, as regular users, and built a .so (LD_PRELOAD'd) that
remaps the various chown, chmod, rename, chdir, etc functions so you
can write them out to a file. This way you can bac
reciever, but it'd be nice if there
> was a less sledge-hammer approach to the chown problem :)
>
> What's the generally accepted method for network backups using
> rsync-like tools?
>
> Ed
I don't know about "generally accepted", but this is what I do..
there
> was a less sledge-hammer approach to the chown problem :)
>
> What's the generally accepted method for network backups using
> rsync-like tools?
>
There are a number of ways to 'skin this particular cat' :)
I made some notes on setting up file servers with
Hi!
I'm stuck trying to find a nice way to allow rsync / rdiff-backup enough
permissions to keep ownership information intact at the backup-receiving
end.
I /could/ run as root on the backup-reciever, but it'd be nice if there
was a less sledge-hammer approach to the chown problem :)
http://debian.aero.und.edu/debian/dists/stable/contrib/source/Sources
302 Found
E: Some index files failed to download, they have been ignored, or old
ones used instead.
If I do a chown -R root.root /var/www/debian.aero.und.edu/html, it will
work ok. I have, of course, automated this, but I was
hi,
i logged in as root,and i did below:
mount /dev/hde5 /mnt/lfs
mkdir /mnt/lfs/sources
chown lfs /mnt/lfs/sources
when i used chown command,it showed "operation not permitted"~~
why did this happen?what should i do??
/dev/hde5 fs is reiserfs~i want to build LFS in user"lf
On Dec-28 2003, Sun, 18:43 -0500
Peter Leftwich <[EMAIL PROTECTED]> wrote:
> # chown root /mnt/test
> chown: changing ownership of `test': Read-only file system
Does dmesg reveal any clues as to why the fs is readonly?
--
Tomas Szepe <[EMAIL PROTECTED]>
--
T
On Mon, 29 Dec 2003, Martin Schlemmer wrote:
> Uhm, if /mnt/test is in a ro filesystem, mounting a partition to it
> rw will still not get you to change /mnt/test - sure, you will be
> able to chown /mnt/test/foo
> Martin Schlemmer
The first slash "/" of /mnt/test is
/mnt/test type ufs (rw,ufstype=44bsd)
>
> # ls -al /mnt | grep knoppix
> drwxr-x--x 25 knoppix root 1024 Dec 18 22:10 /mnt/test
>
> # grep ufs /proc/filesystems
> ufs
>
> # chown root /mnt/test
> chown: changing ownership of `test': Read-onl
c 18 22:10 /mnt/test
# grep ufs /proc/filesystems
ufs
# chown root /mnt/test
chown: changing ownership of `test': Read-only file system
The error above contradicts the "mount" info, namely, the "rw" part!!
Is this a BUG? Might a fix be to give the user "k
On Sun, Apr 29, 2001 at 08:04:18PM +, Victor wrote:
> Any suggestion?
> I'm reproposing my previous message.
> By the way, when it all happened I was either root or sued from a user login.
> Vittorio
> -- Forwarded Message --
> Subject: Dselect chown: r
Any suggestion?
I'm reproposing my previous message.
By the way, when it all happened I was either root or sued from a user login.
Vittorio
-- Forwarded Message --
Subject: Dselect chown: root.root: invalid group
Date: Fri, 27 Apr 2001 12:21:53 +
From: Victor &l
gured:
.
(Reading database ... 85443 files and directories currently installed.)
Unpacking devscripts (from .../devel/devscripts_2.5.8.1.deb) ...
Setting up devscripts (2.5.8.1) ...
chown: root.root: invalid group
dpkg: error processing devscripts (--configure):
subprocess post-installation script ret
ot; actually is a "security
> risk" because you have to replace the simple command line above with
> something more complicated that saves/restores the permissions.
good point, i agree the s removal on chown/chgrp seems largely silly,
one other argument i can think of is it avoids f
> "Ethan" == Ethan Benson <[EMAIL PROTECTED]> writes:
Ethan> your test mail never entered the mail queue, since you
Ethan> don't have a world writable maildrop (this is not
Ethan> /var/mail) it was impossible for the message to get
Ethan> inserted into the postfix mail queue.
On Sun, Feb 25, 2001 at 09:51:29AM +1100, Brian May wrote:
> Hello,
>
> yesterday I changed some of my UID and GID assignments. Including
> GID=postdrop, used by postfix.
this type of change needs to be done very carefully, you really should
not do it while things are running under a uid you are
Hello,
yesterday I changed some of my UID and GID assignments. Including
GID=postdrop, used by postfix.
So I did:
chgrp postdrop /usr/sbin/postdrop /var/spool/postfix/postdrop
and restarted postfix. Fortunately, I ran a test mail, to ensure that
mail was still working - it wasn't.
The reason?
> {
> > user = $1
> > group = $4
> > home = $6
> > }
> > home ~ /^\/home\// {
> > cmd = sprintf( "chown -R %s:%s %s", user, group, home )
> > system( cmd )
> > }
> > ' /etc/passwd
> > Of course you would have to be root first.
24 Jan 2000, John Foster wrote:
> >
> > Well, the following would be a start:
> >
> > awk -F: '
> > {
> > user = $1
> > group = $4
> > home = $6
> > }
>
On Mon, 24 Jan 2000, John Foster wrote:
>=that the result is the changing of the owner/group of every file on my
>=complete directory tree to a single username.groupname. Any Suggestions
I have done the same lately on /usr. Very funny.
The possible solutions as I can see are:
= if you have a ba
John Foster wrote:
>
> What I did was:
>
> "chown -R user:user /"
>
> I meant to put the directory name to change these to; however my finger
> spazzed out and I hit the enter key. The result was that every file and
> directory was affected. I folowed some ad
What I did was:
"chown -R user:user /"
I meant to put the directory name to change these to; however my finger
spazzed out and I hit the enter key. The result was that every file and
directory was affected. I folowed some advises and got most of the
system restored, however my mail re
Well this is a first. I do not even know exactly what I did. I do know
that the result is the changing of the owner/group of every file on my
complete directory tree to a single username.groupname. Any Suggestions
are really appreciated. Wierd thing is everything seems to work--some
things even bet
This basically reprises a message sent on 1999-11-07 at 06:10:18 +,
Subject: Cannot chown /dev/pts/0 to 0,0; likewise for /dev/ptyxx,
which received no response.
On starting xinit, the xterm it brings up only displays characters
as solid blocks of color the foreground color.
When the xterm
/lib/X11/fonts/100dpi"
Then, after a Ctrl-D exits the xterm and kills the X server,
these messages appear:
Cannot chown /dev/pts/0 to 0,0: No such file or directory
Cannot chown /dev/ptyxx to 0,0: No such file or directory
Doing ls -l /dev/pts/0 yields:
crw--w1 root tty 136,
Paul Nathan Puri writes:
> I want to change pon and poff to be owned by users. How do
> I change them with chown?
Why do you want to do this? It won't make it possible for the users to
start ppp. To do that you must put the users in the 'dip' group.
--
John Hasler
[E
On Tue, Feb 23, 1999 at 06:40:30AM +, Paul Nathan Puri wrote:
> I want to change pon and poff to be owned by users. How do
> I change them with chown?
Paul,
If all you want is for non-root users to be able to start and stop a
ppp connection, the recommended way is to add each priv
1 - 100 of 115 matches
Mail list logo
