Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

rsync: failed to set times: Operation not permitted

2,068 views
Skip to first unread message

bad sector

unread,
Oct 18, 2014, 9:52:28 PM10/18/14
to

I'm getting an rsync eror message:

receiving file list ...
85 files to consider
rsync: failed to set times on "/0/sa14/comp/fix-os131/moz/moz-i586/.":
Operation not permitted (1)

The path shown

/0/sa14/comp/fix-os131/moz/moz-i586/

is a data path read-write by all so I'm at a loss for what is 'not
permitted'.



MarkA

unread,
Oct 19, 2014, 12:06:12 AM10/19/14
to
It could be that the type of filesystem you are copying to doesn't
support the same time attributes as the one being copied.

--
MarkA

"Real knowledge is to know the extent of one's ignorance" -- Confucius

HASM

unread,
Oct 19, 2014, 12:12:16 PM10/19/14
to
MarkA <som...@somewhere.invalid> writes:


>> I'm getting an rsync eror message:
>> 85 files to consider rsync: failed to set times on
>> Operation not permitted (1)

> It could be that the type of filesystem you are copying to doesn't
> support the same time attributes as the one being copied.

Most likely. Happens to me every time I rsync to a NetApp server that is
emulating NTFS.

-- HASM

William Unruh

unread,
Oct 19, 2014, 12:29:21 PM10/19/14
to
It is a permissions problem. rsync not only transfers the contents of
the file but also sets the mtime and ctime to be the same as the original
(modification time and creation time). Something is not allowing it to
set those times. Filesystem which does not have those times?

>
>
>

MarkA

unread,
Oct 19, 2014, 2:47:01 PM10/19/14
to
It's not a permissions problem if the transfer is to a different type of
filesystem that doesn't have the attributes that are supposed to be

bad sector

unread,
Oct 19, 2014, 3:48:51 PM10/19/14
to
The target fs is ext4, that's why I don't get it. It's not a problem in
that the files all get downloaded without any problem, but it's a
question mark for me.


William Unruh

unread,
Oct 19, 2014, 3:53:36 PM10/19/14
to
In the sense I used it it is. If the filesystem does not have those
attributes then you have no permission to change those attributes.
>
>
>

William Unruh

unread,
Oct 19, 2014, 3:54:39 PM10/19/14
to
Try running rsync again and look at the error messages and the files
which it claims to have trouble with.

>

Richard Kettlewell

unread,
Oct 19, 2014, 3:59:12 PM10/19/14
to
I would guess that you are running rsync as some user other than the
owner of the directory.

--
http://www.greenend.org.uk/rjk/

bad sector

unread,
Oct 19, 2014, 10:58:16 PM10/19/14
to
The owner was root, the group was users and read-write was unrestricted
all around i.e. owner, users and group. I ran the script as user u3 who
is a member of group users also.

To TS I changed the owner to user u3 and ran the script again and
although there were only a few files to download the error did not recur.

So, why would read-write permission by all be insufficient? I mean if
the files are being written and deleted then why would the timestamp of
a file that has just been downloaded by the same script be impossible to
overwrite? On the other hand if the timestamp in question is that on
some existing files and not on downloaded ones then why would they need
to be written to at all?


William Unruh

unread,
Oct 19, 2014, 11:09:54 PM10/19/14
to
On 2014-10-20, bad sector <forgetski@postit_INVALID_.gov> wrote:
> On 10/19/2014 03:59 PM, Richard Kettlewell wrote:
>> bad sector <forgetski@postit_INVALID_.gov> writes:
>>
>>> I'm getting an rsync eror message:
>>>
>>> receiving file list ...
>>> 85 files to consider
>>> rsync: failed to set times on "/0/sa14/comp/fix-os131/moz/moz-i586/.":
>>> Operation not permitted (1)
>>>
>>> The path shown
>>>
>>> /0/sa14/comp/fix-os131/moz/moz-i586/
>>>
>>> is a data path read-write by all so I'm at a loss for what is 'not
>>> permitted'.
>>
>> I would guess that you are running rsync as some user other than the
>> owner of the directory.
>
> The owner was root, the group was users and read-write was unrestricted
> all around i.e. owner, users and group. I ran the script as user u3 who
> is a member of group users also.

A user (U3) CANNOT change permissions or times on a file owned by root.
It also cannot change ownership of that file. Ie, if you are going to
transfer files owned by root, the runner of the script needs to be
root.

>
> To TS I changed the owner to user u3 and ran the script again and
> although there were only a few files to download the error did not recur.

Correct.

>
> So, why would read-write permission by all be insufficient? I mean if

Because a user cannot change the ownership of a file away from himself
(a HUGE security hole otherwise) and cannot change the attributes of a
file not owned by himself (for the same reason).

> the files are being written and deleted then why would the timestamp of
> a file that has just been downloaded by the same script be impossible to
> overwrite? On the other hand if the timestamp in question is that on
> some existing files and not on downloaded ones then why would they need
> to be written to at all?

It is on a downloaded file.
>
>

bad sector

unread,
Oct 19, 2014, 11:29:42 PM10/19/14
to
On 10/19/2014 11:09 PM, William Unruh wrote:
> On 2014-10-20, bad sector <forgetski@postit_INVALID_.gov> wrote:

>> So, why would read-write permission by all be insufficient? I mean if
>
> Because a user cannot change the ownership of a file away from himself
> (a HUGE security hole otherwise) and cannot change the attributes of a
> file not owned by himself (for the same reason).

The purpose of the script was to allow any user to run the repo sync
before doing an update. The gui update (Suse Yast in this case) requires
root pwd. So I thought that an owner (rot) who is not any particular
user and unconstrained group privs would be the way to go.

WRONG, I guess. My other option might be to assign the script to root or
any user and let any user run it with sudo. That would be no less a
security risk, although in my case security is not a major issue.


Richard Kettlewell

unread,
Oct 20, 2014, 4:25:18 AM10/20/14
to
bad sector <forgetski@postit_INVALID_.gov> writes:
> On 10/19/2014 03:59 PM, Richard Kettlewell wrote:

>> I would guess that you are running rsync as some user other than the
>> owner of the directory.
>
> The owner was root, the group was users and read-write was
> unrestricted all around i.e. owner, users and group. I ran the script
> as user u3 who is a member of group users also.
>
> To TS I changed the owner to user u3 and ran the script again and
> although there were only a few files to download the error did not
> recur.
>
> So, why would read-write permission by all be insufficient?

Because that’s the behavior the OS implements. It could be expressed as
“you can lie about the last modification/access time of your own files,
but not anyone else’s”.

> I mean if the files are being written and deleted then why would the
> timestamp of a file that has just been downloaded by the same script
> be impossible to overwrite? On the other hand if the timestamp in
> question is that on some existing files and not on downloaded ones
> then why would they need to be written to at all?

I’m not sure what you’re asking here. The OS has no idea what the
origin of the files is, it just sees the read/write/utimes/etc calls.

--
http://www.greenend.org.uk/rjk/

Jasen Betts

unread,
Oct 20, 2014, 2:23:38 AM10/20/14
to
what are the mount options?



--
umop apisdn

William Unruh

unread,
Oct 20, 2014, 11:17:28 AM10/20/14
to
On 2014-10-20, bad sector <forgetski@postit_INVALID_.gov> wrote:
> On 10/19/2014 11:09 PM, William Unruh wrote:
>> On 2014-10-20, bad sector <forgetski@postit_INVALID_.gov> wrote:
>
>>> So, why would read-write permission by all be insufficient? I mean if
>>
>> Because a user cannot change the ownership of a file away from himself
>> (a HUGE security hole otherwise) and cannot change the attributes of a
>> file not owned by himself (for the same reason).
>
> The purpose of the script was to allow any user to run the repo sync
> before doing an update. The gui update (Suse Yast in this case) requires
> root pwd. So I thought that an owner (rot) who is not any particular
> user and unconstrained group privs would be the way to go.

Users also cannot do updates for a very good reason. It requires root
priv.
>
> WRONG, I guess. My other option might be to assign the script to root or
> any user and let any user run it with sudo. That would be no less a
> security risk, although in my case security is not a major issue.

Only users who you trust should be allowed to update stuff. Otherwise it
becomes trivial for them to set things up so they can become root, or
destroy everything.

>
>

bad sector

unread,
Oct 20, 2014, 9:04:10 PM10/20/14
to
Most of my users are also in group trusted and those can do updates,
that angle is covered. The problem is that all such users cannot rsync
the local tree CLEANLY prior to such an update without getting similar
root privs. The rsync error cited was just a nuisance because the files
got downloaded anyway and the subsequent update went ahead anyway. It's
just that it doesn't look 'clean' with such error messages floating about.


William Unruh

unread,
Oct 21, 2014, 12:17:33 AM10/21/14
to
Correct, they need root priviledges to change ownership of the files
from themselves to someone else (eg root) or to change the time on files
they do not own. (Now when downloaded they do own them, so they might
get the correct times. Try looking at
ls -lga --time=atime name/of/file
ls -lga --time=ctime name/of/file
ls -lga name/of/file

>
>
0 new messages