I just spent an hour or more (on dial-up line) downloading the latest
version of the SeaMonkey Internet Suite and ended up with nothing except
this error message:-

Quote
/home/daniel/Download/seamonkey-1.1.11.en-us.linux.i686.installer.tar.gz
could not be saved, because you cannot change the contents of that folder.

Change the folder properties and try again, or try saving in a different
location

OK
End Quote

Seems the properties on my Download folder have been set so that only
root can use it. Anybody know how I can change this so that I, as the
only user, can save files to it?

(I have previously saved stuff to the folder, don't know what I've
changed to muck things up)

TKS

Daniel
** Posted from http://www.teranews.com **

On Tuesday 22 July 2008 13:01, someone identifying as *Daniel* wrote
in /alt.os.linux.mandriva:/

> I just spent an hour or more (on dial-up line) downloading the latest
> version of the SeaMonkey Internet Suite and ended up with nothing except
> this error message:-
>
> Quote
> /home/daniel/Download/seamonkey-1.1.11.en-us.linux.i686.installer.tar.gz
> could not be saved, because you cannot change the contents of that folder.
>
> Change the folder properties and try again, or try saving in a different
> location
>
> OK
> End Quote
>
> Seems the properties on my Download folder have been set so that only
> root can use it.

This means that either you yourself changed ownership of that directory -
please don't call it a "folder" ;-) - to the root user then, or that
perhaps by accident you had deleted this directory and recreated it again
while being logged in as root.

Another possibility would be that you've unset the write permission for
yourself on that directory. Anyway, I will list your options below... ;-)

> Anybody know how I can change this so that I, as the
> only user, can save files to it?

First, open up a terminal window. I presume you're using KDE, so you should
have /Konsole/ available in your menus, or even as an icon on the /Kicker/
panel.

Now, you should find yourself with a commandline in your home directory, of
which the *./Downloads* directory is a subdirectory. First, enter the
following command...:

ls -ld ./Downloads

Check who is set as the owner, and what group the directory belong to. If
this is not your user account, you must /su/ to the root account, but
without changing the current working directory, like this...

su

.... and then you must set it up so that your regular user account is the
owner again, and so that the owning group for that directory is the primary
group your user account belongs to.

Now I don't know what the primary group for a user account is in the latest
Mandriva releases, but up until Mandrake 10.0 - which I'm using on this
machine here - this used to be a group with the same name as the login.
So, in the example below, substitute the proper group if needed...

chown daniel.daniel ./Downloads

Now, if the permissions mask was wrong too, issue the following command...:

chmod 700 ./Downloads

The above gives read, write and execute(/traverse) permission to the owner
of the directory - which should now be your unprivileged user account - but
not to anyone in your primary group. If you need someone in the same group
to have read and execute permission on that directory - I strongly
recommend not giving write permission - then change /700/ by /750/ in the
above command.

Now you can check again...

ls -ld ./Downloads

If all is as it should be, you can press /Ctrl+D/ to log out of the root
environment and return to your regular user account. If you want to close
the terminal window, press /Ctrl+D/ again.

In the event that you are somewhat puzzled by the numerical codes I've given
you higher up, here's how it works: Each file or directory has a
permissions mask, and if we don't include the first character of that
permissions mask - which is a dash for a regular file, an "l" for a
symlink, a "d" for a directory, etc. - then you've got nine characters,
composed of three groups of three characters.

The first group of three permission characters - r, w and x - are for the
owner of the file or directory - usually called "the user". The second
group of three permission characters is for the group. The third group is
for everyone else, excluding the root user since root has access to
everything.

Now, if you look at the /rwx/ mask within one group, you must realize that
these are only bits, i.e. they can be switched on or off. If they're off,
then there's a dash. If they're on, then there's a character, depending on
the type of permission.

So in effect, you have a three-bit mask for each of the three permissions
groups - one for the user, one for the group, one for the others - which
means that all values of that three-bit mask can make up for a total of 8
combinations.

So we can use an octal notation to manipulate the permissions, using three
octal numbers, one for each set of three permissions within the entire
permissions mask.

For the owner of the directory in this case, we want him - i.e. your user
account "daniel" - to have read, write and execute permission. This means
all three bits are on, and so in binary code, that would be "111". In
octal code, this makes 7.

(Note: it would also make up for "7" in decimal code, but octal code doesn't
have the numbers "8" and "9", and since the permissions group cannot have a
value higher than "7", there is no need for a decimal system. The octal
system uses the numbers 0 to 7, just like the binary system uses 0 to 1.)

And thus, with three octal numbers, we can set the permissions mask for all
permissions bits. At least, for regular files and directories, because you
can add a fourth and even a fifth octal number (in front of the others)
which allows you to set special permissions on a file, like the /suid/ bit
or the /sgid/ bit, or any of the other more complex variants the UNIX
permissions system allows.

For instance, /1777/ is the proper permissions mask for */tmp* - the "1"
sets the sticky bit (+t) and "777" makes it world-readable, world-writable
and world-traversable. The use "world" here should be interpreted in the
restricted sense of course that it simply represents "user, owner and all
others", with the "others" being the user accounts on the system which are
not in the group for the file/directory.

Anyway, the above should do the trick, unless you've set up an ACL for that
particular directory. I haven't got any experience with those on GNU/Linux
- I did set up ACLs on Windows NT once, but that was entirely GUI-driven
and it was a very long time ago. So if that is the case, then someone else
may point you in the right direction, but I have a feeling that this won't
be what caused the problem on your system. ;-)

Hope this was helpful... :-)

--
*Aragorn*
(registered GNU/Linux user #223157)

On Tue, 22 Jul 2008 21:01:20 +1000, Daniel wrote:
>
> Quote
> /home/daniel/Download/seamonkey-1.1.11.en-us.linux.i686.installer.tar.gz
> could not be saved, because you cannot change the contents of that folder.
>
> Change the folder properties and try again, or try saving in a different
> location
>
>
> Seems the properties on my Download folder have been set so that only
> root can use it. Anybody know how I can change this so that I, as the
> only user, can save files to it?

Yes. Click up a terminal
man chmod
man dhown


> (I have previously saved stuff to the folder, don't know what I've
> changed to muck things up)

Guessing, you logged into root with su root instead of using su - root
That left you in daniel's account as root and any directory/file
creation activity wound up being owned as root.
Or, you copied thing into daniel's account logged in as root
and did not set ownership to daniel before exiting root.

To check for damage, as daniel, do a
ls -al
ls -al Download/*
and check ownership of files and directories.

my suggestion.

su - root
cd /home
chown -R daniel:daniel daniel
exit

--
The warranty and liability expired as you read this message.
If the above breaks your system, it's yours and you keep both pieces.
Practice safe computing. Backup the file before you change it.
Do a, man command_here or cat command_here, before using it.

On Tue, 22 Jul 2008 14:36:45 +0200, Aragorn wrote:
>
> chown daniel.daniel ./Downloads

shuckey dern, I would have guessed daniel.daniel would have failed
since man chown suggests daniel:daniel

Should daniel.daniel be reported as a bug...... :-)

> Anyway, the above should do the trick, unless you've set up an ACL for that
> particular directory. I haven't got any experience with those on GNU/Linux

Oh, you'll enjoy those, example:

chcon system_u:object_r:textrel_shlib_t libflashplayer.so

On Tuesday 22 July 2008 14:57, someone identifying as *Bit Twister* wrote
in /alt.os.linux.mandriva:/

> On Tue, 22 Jul 2008 14:36:45 +0200, Aragorn wrote:
>>
>> chown daniel.daniel ./Downloads
>
> shuckey dern, I would have guessed daniel.daniel would have failed
> since man chown suggests daniel:daniel
>
> Should daniel.daniel be reported as a bug...... :-)

I distinctly remember that in Mandrake 6.0, I was able to use a user account
with uppercase characters and a period in them, but in later versions, this
was no longer allowed, so that the period was interpreted as a separation
between the name of the login account and the name of a group in a /chown/
command.

I don't think it's a bug, but perhaps an undocumented feature. A colon
should however be considered the appropriate way to do it. ;-)

--
*Aragorn*
(registered GNU/Linux user #223157)

Daniel <dxmm@albury.nospam.net.au> writes:

>I just spent an hour or more (on dial-up line) downloading the latest
>version of the SeaMonkey Internet Suite and ended up with nothing except
>this error message:-

>Quote
>/home/daniel/Download/seamonkey-1.1.11.en-us.linux.i686.installer.tar.gz
>could not be saved, because you cannot change the contents of that folder.

>Change the folder properties and try again, or try saving in a different
>location

It would be nice if instead of throwing away the download the system gave
you the option of specifying a different location. As you say, wasting an
hour on an easily fixable thing is pretty annoying.

s is why I almost always download to /tmp The permissions are right for
that.



>OK
>End Quote

>Seems the properties on my Download folder have been set so that only
>root can use it. Anybody know how I can change this so that I, as the
>only user, can save files to it?

well. check it
ls -ld Download
Then use chmod or chown to change the permissions or ownership of that
subdirectory.


>(I have previously saved stuff to the folder, don't know what I've
>changed to muck things up)

On Tue, 22 Jul 2008 08:57:05 -0400, Bit Twister <BitTwister@mouse-potato.com> wrote:

> Oh, you'll enjoy those, example:
> chcon system_u:object_r:textrel_shlib_t libflashplayer.so

That's a really well documented command! :)

Found a little bit at http://docs.fedoraproject.org/selinu...fc5/#id2922626

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

Bit Twister wrote:
> On Tue, 22 Jul 2008 21:01:20 +1000, Daniel wrote:
>> Quote
>> /home/daniel/Download/seamonkey-1.1.11.en-us.linux.i686.installer.tar.gz
>> could not be saved, because you cannot change the contents of that folder.
>>
>> Change the folder properties and try again, or try saving in a different
>> location
>>
>>
>> Seems the properties on my Download folder have been set so that only
>> root can use it. Anybody know how I can change this so that I, as the
>> only user, can save files to it?
>
> Yes. Click up a terminal
> man chmod
> man dhown
>
>
>> (I have previously saved stuff to the folder, don't know what I've
>> changed to muck things up)
>
> Guessing, you logged into root with su root instead of using su - root
> That left you in daniel's account as root and any directory/file
> creation activity wound up being owned as root.
> Or, you copied thing into daniel's account logged in as root
> and did not set ownership to daniel before exiting root.
>
> To check for damage, as daniel, do a
> ls -al
> ls -al Download/*
> and check ownership of files and directories.
>
> my suggestion.
>
> su - root
> cd /home
> chown -R daniel:daniel daniel
> exit
>

BT, I usually log in with su and then give my password, so does this
leave me as root in my profile or as root in root's profile (my guess)?

Several of my mount points had root:root permission, but I've now
changed them to daniel:daniel.

Thanks.

Daniel
** Posted from http://www.teranews.com **

Unruh wrote:
> Daniel <dxmm@albury.nospam.net.au> writes:
>
>> I just spent an hour or more (on dial-up line) downloading the latest
>> version of the SeaMonkey Internet Suite and ended up with nothing except
>> this error message:-
>
>> Quote
>> /home/daniel/Download/seamonkey-1.1.11.en-us.linux.i686.installer.tar.gz
>> could not be saved, because you cannot change the contents of that folder.
>
>> Change the folder properties and try again, or try saving in a different
>> location
>
> It would be nice if instead of throwing away the download the system gave
> you the option of specifying a different location. As you say, wasting an
> hour on an easily fixable thing is pretty annoying.

Yes, giving me a second/third chance would be nice......maybe it's saved
in my SeaMonkey Browser's cache, so, hopefully, I'll just have to change
the name!!

Daniel

>
> s is why I almost always download to /tmp The permissions are right for
> that.
>
>
>
>> OK
>> End Quote
>
>> Seems the properties on my Download folder have been set so that only
>> root can use it. Anybody know how I can change this so that I, as the
>> only user, can save files to it?
>
> well. check it
> ls -ld Download
> Then use chmod or chown to change the permissions or ownership of that
> subdirectory.
>
>
>> (I have previously saved stuff to the folder, don't know what I've
>> changed to muck things up)
>
** Posted from http://www.teranews.com **

Aragorn wrote:
> On Tuesday 22 July 2008 13:01, someone identifying as *Daniel* wrote
> in /alt.os.linux.mandriva:/
>
>> I just spent an hour or more (on dial-up line) downloading the latest
>> version of the SeaMonkey Internet Suite and ended up with nothing except
>> this error message:-
>>
>> Quote
>> /home/daniel/Download/seamonkey-1.1.11.en-us.linux.i686.installer.tar.gz
>> could not be saved, because you cannot change the contents of that folder.
>>
>> Change the folder properties and try again, or try saving in a different
>> location
>>
>> OK
>> End Quote
>>
>> Seems the properties on my Download folder have been set so that only
>> root can use it.
>
> This means that either you yourself changed ownership of that directory -
> please don't call it a "folder" ;-) - to the root user then, or that
> perhaps by accident you had deleted this directory and recreated it again
> while being logged in as root.
>
> Another possibility would be that you've unset the write permission for
> yourself on that directory. Anyway, I will list your options below... ;-)
>
>> Anybody know how I can change this so that I, as the
>> only user, can save files to it?
>
> First, open up a terminal window. I presume you're using KDE, so you should
> have /Konsole/ available in your menus, or even as an icon on the /Kicker/
> panel.
>
> Now, you should find yourself with a commandline in your home directory, of
> which the *./Downloads* directory is a subdirectory. First, enter the
> following command...:
>
> ls -ld ./Downloads
>
> Check who is set as the owner, and what group the directory belong to. If
> this is not your user account, you must /su/ to the root account, but
> without changing the current working directory, like this...
>
> su
>
> ... and then you must set it up so that your regular user account is the
> owner again, and so that the owning group for that directory is the primary
> group your user account belongs to.
>
> Now I don't know what the primary group for a user account is in the latest
> Mandriva releases, but up until Mandrake 10.0 - which I'm using on this
> machine here - this used to be a group with the same name as the login.
> So, in the example below, substitute the proper group if needed...
>
> chown daniel.daniel ./Downloads
>
> Now, if the permissions mask was wrong too, issue the following command...:
>
> chmod 700 ./Downloads
>
> The above gives read, write and execute(/traverse) permission to the owner
> of the directory - which should now be your unprivileged user account - but
> not to anyone in your primary group. If you need someone in the same group
> to have read and execute permission on that directory - I strongly
> recommend not giving write permission - then change /700/ by /750/ in the
> above command.
>
> Now you can check again...
>
> ls -ld ./Downloads
>
> If all is as it should be, you can press /Ctrl+D/ to log out of the root
> environment and return to your regular user account. If you want to close
> the terminal window, press /Ctrl+D/ again.
>
> In the event that you are somewhat puzzled by the numerical codes I've given
> you higher up, here's how it works: Each file or directory has a
> permissions mask, and if we don't include the first character of that
> permissions mask - which is a dash for a regular file, an "l" for a
> symlink, a "d" for a directory, etc. - then you've got nine characters,
> composed of three groups of three characters.
>
> The first group of three permission characters - r, w and x - are for the
> owner of the file or directory - usually called "the user". The second
> group of three permission characters is for the group. The third group is
> for everyone else, excluding the root user since root has access to
> everything.
>
> Now, if you look at the /rwx/ mask within one group, you must realize that
> these are only bits, i.e. they can be switched on or off. If they're off,
> then there's a dash. If they're on, then there's a character, depending on
> the type of permission.
>
> So in effect, you have a three-bit mask for each of the three permissions
> groups - one for the user, one for the group, one for the others - which
> means that all values of that three-bit mask can make up for a total of 8
> combinations.
>
> So we can use an octal notation to manipulate the permissions, using three
> octal numbers, one for each set of three permissions within the entire
> permissions mask.
>
> For the owner of the directory in this case, we want him - i.e. your user
> account "daniel" - to have read, write and execute permission. This means
> all three bits are on, and so in binary code, that would be "111". In
> octal code, this makes 7.
>
> (Note: it would also make up for "7" in decimal code, but octal code doesn't
> have the numbers "8" and "9", and since the permissions group cannot have a
> value higher than "7", there is no need for a decimal system. The octal
> system uses the numbers 0 to 7, just like the binary system uses 0 to 1.)
>
> And thus, with three octal numbers, we can set the permissions mask for all
> permissions bits. At least, for regular files and directories, because you
> can add a fourth and even a fifth octal number (in front of the others)
> which allows you to set special permissions on a file, like the /suid/ bit
> or the /sgid/ bit, or any of the other more complex variants the UNIX
> permissions system allows.
>
> For instance, /1777/ is the proper permissions mask for */tmp* - the "1"
> sets the sticky bit (+t) and "777" makes it world-readable, world-writable
> and world-traversable. The use "world" here should be interpreted in the
> restricted sense of course that it simply represents "user, owner and all
> others", with the "others" being the user accounts on the system which are
> not in the group for the file/directory.
>
> Anyway, the above should do the trick, unless you've set up an ACL for that
> particular directory. I haven't got any experience with those on GNU/Linux
> - I did set up ACLs on Windows NT once, but that was entirely GUI-driven
> and it was a very long time ago. So if that is the case, then someone else
> may point you in the right direction, but I have a feeling that this won't
> be what caused the problem on your system. ;-)
>
> Hope this was helpful... :-)
>

[daniel@P007 ~]$ ls -ld ./Download
drwxr-xr-x 5 root root 3072 May 24 14:32 ./Download/
[daniel@P007 ~]$


Thanks Aragon!

The "chown daniel.daniel ./Download" that you gave above has, hopefully,
fixed things.

And thanks for the revision lesson on Permissions!

Daniel
** Posted from http://www.teranews.com **