tip: ftp permission issues

Hi All,

I have noticed that Cobian Backup to and FTP server can create files
with read only attributes (644). But neither Widows Explorer or Cobian
can delete a folder with one of these files in it. This is clearly a
short coming on Windows 7's part and I don't think M$ will ever
address the issue, so ...

To cope with it, I created a cron job to go off at 23:00 to
change the users' ftp directory permissions back to read write
(755).

etc/crontab

# Clean out the read onlys from folks backing up with ftp (Cobian can
# only delete 755 files and chokes on 644 files
05 23 * * * root chmod -R 755 /home/user1/ftp
10 23 * * * root chmod -R 755 /home/user2/ftp
15 23 * * * root chmod -R 755 /home/user3/ftp
20 23 * * * root chmod -R 755 /home/user4/ftp


Problem solved.

-T

T wrote:
Hi All,

I have noticed that Cobian Backup to and FTP server can create files
with read only attributes (644). But neither Widows Explorer or Cobian
can delete a folder with one of these files in it. This is clearly a
short coming on Windows 7's part and I don't think M$ will ever
address the issue, so ...

To cope with it, I created a cron job to go off at 23:00 to
change the users' ftp directory permissions back to read write
(755).

etc/crontab

# Clean out the read onlys from folks backing up with ftp (Cobian can
# only delete 755 files and chokes on 644 files
05 23 * * * root chmod -R 755 /home/user1/ftp
10 23 * * * root chmod -R 755 /home/user2/ftp
15 23 * * * root chmod -R 755 /home/user3/ftp
20 23 * * * root chmod -R 755 /home/user4/ftp


Problem solved.

-T

This helpful tip seems to involve more than
one platform. The audience might understand better
if you hinted the backup client ran on Windows, while
the backup server (which holds all the backups) is Linux.
And the above suggestion is Linux-related for the server
side of your backup.

If you were going to set up the FTP box for anything,
it would be for blind FTP. I cannot tell from this example,
whether you're using ftp or sftp or a secure tunnel or
whatever. Lots of things you might take chances on, while
in the privacy of your own home, you would not do "on-the-job".
This is how people get fired :-) Of course, you only get
fired, after something bad happens. Fingers crossed.

Paul

On 12/29/2016 09:57 PM, Paul wrote:
T wrote:
Hi All,

I have noticed that Cobian Backup to and FTP server can create files
with read only attributes (644). But neither Widows Explorer or Cobian
can delete a folder with one of these files in it. This is clearly a
short coming on Windows 7's part and I don't think M$ will ever
address the issue, so ...

To cope with it, I created a cron job to go off at 23:00 to
change the users' ftp directory permissions back to read write
(755).

etc/crontab

# Clean out the read onlys from folks backing up with ftp (Cobian can
# only delete 755 files and chokes on 644 files
05 23 * * * root chmod -R 755 /home/user1/ftp
10 23 * * * root chmod -R 755 /home/user2/ftp
15 23 * * * root chmod -R 755 /home/user3/ftp
20 23 * * * root chmod -R 755 /home/user4/ftp


Problem solved.

-T

This helpful tip seems to involve more than
one platform. The audience might understand better
if you hinted the backup client ran on Windows, while
the backup server (which holds all the backups) is Linux.
And the above suggestion is Linux-related for the server
side of your backup.

If you were going to set up the FTP box for anything,
it would be for blind FTP. I cannot tell from this example,
whether you're using ftp or sftp or a secure tunnel or
whatever. Lots of things you might take chances on, while
in the privacy of your own home, you would not do "on-the-job".
This is how people get fired :-) Of course, you only get
fired, after something bad happens. Fingers crossed.

Paul

Hi Paul,

In an effort to avoid ransomware, a second backup is done using Cobian
Backup from the Windows Clients to a Linux FTP server. No drive letter
involved. It is all on a customer's site. No Internet involved.
And a nasty firewall -- an actual real firewall, not NAT -- that
I administer.

It is annoying that you can create read only files with Cobian
and Windows Explorer on the FTP server, but then they are
permanent, unless you ssh into the server and delete then
through Linux. With 644 permissions, the user is given
the rights to erase things too. But Windows coughs anyway.

It is also annoying that Cobian and Windows Explorer can copy
directories with "+++" in their file name (Firefox's "storage"
directory), but can not remove them for your life. I have
filters set up in Cobian to avoid them.

And the users also have a local backup drive. I have put in
place some rather interesting barriers to ransomware on
them too. But that is a story for another day.

Me no get fired.

-T

T wrote:
On 12/29/2016 09:57 PM, Paul wrote:
T wrote:
Hi All,

I have noticed that Cobian Backup to and FTP server can create files
with read only attributes (644). But neither Widows Explorer or Cobian
can delete a folder with one of these files in it. This is clearly a
short coming on Windows 7's part and I don't think M$ will ever
address the issue, so ...

To cope with it, I created a cron job to go off at 23:00 to
change the users' ftp directory permissions back to read write
(755).

etc/crontab

# Clean out the read onlys from folks backing up with ftp (Cobian can
# only delete 755 files and chokes on 644 files
05 23 * * * root chmod -R 755 /home/user1/ftp
10 23 * * * root chmod -R 755 /home/user2/ftp
15 23 * * * root chmod -R 755 /home/user3/ftp
20 23 * * * root chmod -R 755 /home/user4/ftp


Problem solved.

-T

This helpful tip seems to involve more than
one platform. The audience might understand better
if you hinted the backup client ran on Windows, while
the backup server (which holds all the backups) is Linux.
And the above suggestion is Linux-related for the server
side of your backup.

If you were going to set up the FTP box for anything,
it would be for blind FTP. I cannot tell from this example,
whether you're using ftp or sftp or a secure tunnel or
whatever. Lots of things you might take chances on, while
in the privacy of your own home, you would not do "on-the-job".
This is how people get fired :-) Of course, you only get
fired, after something bad happens. Fingers crossed.

Paul

Hi Paul,

In an effort to avoid ransomware, a second backup is done using Cobian
Backup from the Windows Clients to a Linux FTP server. No drive letter
involved. It is all on a customer's site. No Internet involved.
And a nasty firewall -- an actual real firewall, not NAT -- that
I administer.

It is annoying that you can create read only files with Cobian
and Windows Explorer on the FTP server, but then they are
permanent, unless you ssh into the server and delete then
through Linux. With 644 permissions, the user is given
the rights to erase things too. But Windows coughs anyway.

It is also annoying that Cobian and Windows Explorer can copy
directories with "+++" in their file name (Firefox's "storage"
directory), but can not remove them for your life. I have
filters set up in Cobian to avoid them.

And the users also have a local backup drive. I have put in
place some rather interesting barriers to ransomware on
them too. But that is a story for another day.

Me no get fired.

-T

What if you were to create an NTFS partition for the backups.
Would that crush permissions for you ? (That is, an NTFS partition
on a Linux system, where Linux doesn't care about NTFS partitions,
and NTFS can handle extremely large files.)

And does Cobian have any provision for name collisions ?

Or for that matter, does Cobian handle Alternate Streams
at all ? I don't see how it can do that, when using "file
storage" as an output means, and not a proprietary image format.
With an image, you can hide all sorts of stuff. This is sorta
like the Apple binhex problem ("It is similar to Uuencode, but
combined both forks of the Mac file system together along with
extended file information"). I suppose it could store
a file as two separate files, then bolt together the
alternate streams on a restore. Alternate Streams are used
for downloads, to mark that they came in off the "dirty"
Internet. That's an example of an application of an
Alternate Stream.

Paul

T wrote:
Hi All,

I have noticed that Cobian Backup to and FTP server can create files
with read only attributes (644). But neither Widows Explorer or Cobian
can delete a folder with one of these files in it. This is clearly a
short coming on Windows 7's part and I don't think M$ will ever
address the issue, so ...

To cope with it, I created a cron job to go off at 23:00 to
change the users' ftp directory permissions back to read write
(755).

etc/crontab

# Clean out the read onlys from folks backing up with ftp (Cobian can
# only delete 755 files and chokes on 644 files
05 23 * * * root chmod -R 755 /home/user1/ftp
10 23 * * * root chmod -R 755 /home/user2/ftp
15 23 * * * root chmod -R 755 /home/user3/ftp
20 23 * * * root chmod -R 755 /home/user4/ftp


Problem solved.

-T


I tried testing Cobian, and as a test case, asked
it to back up all of C: .

Based on the permissions problems, are you actually
using it for that, or just for user folders ?

I didn't seem to have a problem with my FTP server.
I installed Filezilla as 127.0.0.1 on the same VM,
so all the testing could be done on one VM to start.
And the setup of FTP didn't present a problem. It
seemed to be working.

Based on the method it appears to be using, it
doesn't look like an Alternate Stream would be
preserved.

Paul

On 12/30/2016 12:03 AM, Paul wrote:
T wrote:
On 12/29/2016 09:57 PM, Paul wrote:
T wrote:
Hi All,

I have noticed that Cobian Backup to and FTP server can create files
with read only attributes (644). But neither Widows Explorer or Cobian
can delete a folder with one of these files in it. This is clearly a
short coming on Windows 7's part and I don't think M$ will ever
address the issue, so ...

To cope with it, I created a cron job to go off at 23:00 to
change the users' ftp directory permissions back to read write
(755).

etc/crontab

# Clean out the read onlys from folks backing up with ftp (Cobian can
# only delete 755 files and chokes on 644 files
05 23 * * * root chmod -R 755 /home/user1/ftp
10 23 * * * root chmod -R 755 /home/user2/ftp
15 23 * * * root chmod -R 755 /home/user3/ftp
20 23 * * * root chmod -R 755 /home/user4/ftp


Problem solved.

-T

This helpful tip seems to involve more than
one platform. The audience might understand better
if you hinted the backup client ran on Windows, while
the backup server (which holds all the backups) is Linux.
And the above suggestion is Linux-related for the server
side of your backup.

If you were going to set up the FTP box for anything,
it would be for blind FTP. I cannot tell from this example,
whether you're using ftp or sftp or a secure tunnel or
whatever. Lots of things you might take chances on, while
in the privacy of your own home, you would not do "on-the-job".
This is how people get fired :-) Of course, you only get
fired, after something bad happens. Fingers crossed.

Paul

Hi Paul,

In an effort to avoid ransomware, a second backup is done using Cobian
Backup from the Windows Clients to a Linux FTP server. No drive letter
involved. It is all on a customer's site. No Internet involved.
And a nasty firewall -- an actual real firewall, not NAT -- that
I administer.

It is annoying that you can create read only files with Cobian
and Windows Explorer on the FTP server, but then they are
permanent, unless you ssh into the server and delete then
through Linux. With 644 permissions, the user is given
the rights to erase things too. But Windows coughs anyway.

It is also annoying that Cobian and Windows Explorer can copy
directories with "+++" in their file name (Firefox's "storage"
directory), but can not remove them for your life. I have
filters set up in Cobian to avoid them.

And the users also have a local backup drive. I have put in
place some rather interesting barriers to ransomware on
them too. But that is a story for another day.

Me no get fired.

-T

What if you were to create an NTFS partition for the backups.

That is what I do on local backup disks. Fat(32) has its limitations

Would that crush permissions for you ? (That is, an NTFS partition
on a Linux system, where Linux doesn't care about NTFS partitions,
and NTFS can handle extremely large files.)

That is not cifs (Windows) file sharing works in Linux's
cifs server (Samba). The permissions are "mapped" and
they work fine. Windows Explorer has no issues with
read only files on a Samba file server.


And does Cobian have any provision for name collisions ?

Yep. Just over writes them


Or for that matter, does Cobian handle Alternate Streams
at all ? I don't see how it can do that, when using "file
storage" as an output means, and not a proprietary image format.
With an image, you can hide all sorts of stuff. This is sorta
like the Apple binhex problem ("It is similar to Uuencode, but
combined both forks of the Mac file system together along with
extended file information"). I suppose it could store
a file as two separate files, then bolt together the
alternate streams on a restore. Alternate Streams are used
for downloads, to mark that they came in off the "dirty"
Internet. That's an example of an application of an
Alternate Stream.

Paul

I do not know about streams.

With Cobian, and really any backup system for Windows,
you are best to only back up data files. And use Volume
Shadow Copy (Cobian supports it). Windows has too
many weird files that can not be backed up. (with
Linux yo can back up the whole thing lock, stock and
barrel.)

Had some one back up C:\Users with Cobian a few weeks
ago. What a mess. I changed it to My Docs, desktop,
and some stuff in appdata.

So basically, with that type of backup, if the worst happens,
you reinstall Windows and your programs, then recover your
data files.

This works out well as Windows gets weird(er) with time
and a good reinstall cleans out the accumulated trash.

On 12/30/2016 01:17 PM, Paul wrote:
T wrote:
Hi All,

I have noticed that Cobian Backup to and FTP server can create files
with read only attributes (644). But neither Widows Explorer or Cobian
can delete a folder with one of these files in it. This is clearly a
short coming on Windows 7's part and I don't think M$ will ever
address the issue, so ...

To cope with it, I created a cron job to go off at 23:00 to
change the users' ftp directory permissions back to read write
(755).

etc/crontab

# Clean out the read onlys from folks backing up with ftp (Cobian can
# only delete 755 files and chokes on 644 files
05 23 * * * root chmod -R 755 /home/user1/ftp
10 23 * * * root chmod -R 755 /home/user2/ftp
15 23 * * * root chmod -R 755 /home/user3/ftp
20 23 * * * root chmod -R 755 /home/user4/ftp


Problem solved.

-T


I tried testing Cobian, and as a test case, asked
it to back up all of C: .

Based on the permissions problems, are you actually
using it for that, or just for user folders ?

I didn't seem to have a problem with my FTP server.
I installed Filezilla as 127.0.0.1 on the same VM,
so all the testing could be done on one VM to start.
And the setup of FTP didn't present a problem. It
seemed to be working.

Based on the method it appears to be using, it
doesn't look like an Alternate Stream would be
preserved.

Paul

What are you using for an ftp server?

And, what are you using to manipulate your files
from Windows?

Here is a test, copy your appdata/mozilla folder
to an ftp location. Make sure it contains a
folder called "storage". then see if you can delete
the "Mozilla" folder.

T wrote:
On 12/30/2016 01:17 PM, Paul wrote:
T wrote:
Hi All,

I have noticed that Cobian Backup to and FTP server can create files
with read only attributes (644). But neither Widows Explorer or Cobian
can delete a folder with one of these files in it. This is clearly a
short coming on Windows 7's part and I don't think M$ will ever
address the issue, so ...

To cope with it, I created a cron job to go off at 23:00 to
change the users' ftp directory permissions back to read write
(755).

etc/crontab

# Clean out the read onlys from folks backing up with ftp (Cobian can
# only delete 755 files and chokes on 644 files
05 23 * * * root chmod -R 755 /home/user1/ftp
10 23 * * * root chmod -R 755 /home/user2/ftp
15 23 * * * root chmod -R 755 /home/user3/ftp
20 23 * * * root chmod -R 755 /home/user4/ftp


Problem solved.

-T


I tried testing Cobian, and as a test case, asked
it to back up all of C: .

Based on the permissions problems, are you actually
using it for that, or just for user folders ?

I didn't seem to have a problem with my FTP server.
I installed Filezilla as 127.0.0.1 on the same VM,
so all the testing could be done on one VM to start.
And the setup of FTP didn't present a problem. It
seemed to be working.

Based on the method it appears to be using, it
doesn't look like an Alternate Stream would be
preserved.

Paul

What are you using for an ftp server?

And, what are you using to manipulate your files
from Windows?

Here is a test, copy your appdata/mozilla folder
to an ftp location. Make sure it contains a
folder called "storage". then see if you can delete
the "Mozilla" folder.

Filezilla was the Windows FTP server, so I could
do all the testing in a single VM. My file server
is at 127.0.0.1 . The FTP directory for Filezilla
was FAT32 (as nothing on the source is big enough
to hit the FAT32 file limit).

Cobian seemed to have problems with the usual stuff
you would have problems copying as Administrator.

If it was using VSS, it was hard to tell.

As for your comment about backup software in general,
yes, you can find *lots* of backup programs which will
back up everything on C: , including proper handling
of Junction Points, permissions, ownership, Alternate
Streams, Hard Links, and so on. And storage is to an
image in a proprietary format. In some cases, with
export capability to VHD (another kind of image,
which can be opened by more applications including 7ZIP).

And if you really needed a file-by-file backup method,
you'd try Retrospect (Dantz/EMC, not sure who owns it now).
That started far enough back, that it's an expert at
driving tape drives. But did eventually move to supporting
hard drive backups. I used that to automate backups
on 20 partitions on a Macintosh. And also used it on
a PC for someone else.

It's not much of a backup application if it cannot
conquer permissions. I shouldn't have to launch the
thing as SYSTEM to get it to work. And if I did,
I shudder to think what permissions it would stamp
the files with on a restore.

If you're going to do stuff like that, you might want
to back up the permission bits on the file system
with icacls (to a text file) for safe keeping. That
will allow you to restore the permissions, if your backup/restore
method isn't doing a good job.

icacls d:\ /save ntfsDdrive.txt /t /c

icacls d:\ /restore ntfsDdrive.txt

I suppose, in this case, you don't even need a restore
function, as the files in question are "just sitting there".
But, because Cobian claims to support Differential, using
the automation covers cases where features like that
are being used.

HTH,
Paul

On 12/30/2016 04:18 PM, Paul wrote:
T wrote:
On 12/30/2016 01:17 PM, Paul wrote:
T wrote:
Hi All,

I have noticed that Cobian Backup to and FTP server can create files
with read only attributes (644). But neither Widows Explorer or Cobian
can delete a folder with one of these files in it. This is clearly a
short coming on Windows 7's part and I don't think M$ will ever
address the issue, so ...

To cope with it, I created a cron job to go off at 23:00 to
change the users' ftp directory permissions back to read write
(755).

etc/crontab

# Clean out the read onlys from folks backing up with ftp (Cobian can
# only delete 755 files and chokes on 644 files
05 23 * * * root chmod -R 755 /home/user1/ftp
10 23 * * * root chmod -R 755 /home/user2/ftp
15 23 * * * root chmod -R 755 /home/user3/ftp
20 23 * * * root chmod -R 755 /home/user4/ftp


Problem solved.

-T


I tried testing Cobian, and as a test case, asked
it to back up all of C: .

Based on the permissions problems, are you actually
using it for that, or just for user folders ?

I didn't seem to have a problem with my FTP server.
I installed Filezilla as 127.0.0.1 on the same VM,
so all the testing could be done on one VM to start.
And the setup of FTP didn't present a problem. It
seemed to be working.

Based on the method it appears to be using, it
doesn't look like an Alternate Stream would be
preserved.

Paul

What are you using for an ftp server?

And, what are you using to manipulate your files
from Windows?

Here is a test, copy your appdata/mozilla folder
to an ftp location. Make sure it contains a
folder called "storage". then see if you can delete
the "Mozilla" folder.

Filezilla was the Windows FTP server, so I could
do all the testing in a single VM. My file server
is at 127.0.0.1 . The FTP directory for Filezilla
was FAT32 (as nothing on the source is big enough
to hit the FAT32 file limit).

Cobian seemed to have problems with the usual stuff
you would have problems copying as Administrator.

If it was using VSS, it was hard to tell.

As for your comment about backup software in general,
yes, you can find *lots* of backup programs which will
back up everything on C: , including proper handling
of Junction Points, permissions, ownership, Alternate
Streams, Hard Links, and so on. And storage is to an
image in a proprietary format. In some cases, with
export capability to VHD (another kind of image,
which can be opened by more applications including 7ZIP).

And if you really needed a file-by-file backup method,
you'd try Retrospect (Dantz/EMC, not sure who owns it now).
That started far enough back, that it's an expert at
driving tape drives. But did eventually move to supporting
hard drive backups. I used that to automate backups
on 20 partitions on a Macintosh. And also used it on
a PC for someone else.

It's not much of a backup application if it cannot
conquer permissions. I shouldn't have to launch the
thing as SYSTEM to get it to work. And if I did,
I shudder to think what permissions it would stamp
the files with on a restore.

If you're going to do stuff like that, you might want
to back up the permission bits on the file system
with icacls (to a text file) for safe keeping. That
will allow you to restore the permissions, if your backup/restore
method isn't doing a good job.

icacls d:\ /save ntfsDdrive.txt /t /c

icacls d:\ /restore ntfsDdrive.txt

I suppose, in this case, you don't even need a restore
function, as the files in question are "just sitting there".
But, because Cobian claims to support Differential, using
the automation covers cases where features like that
are being used.

HTH,
Paul

The difference between and Linux and a Windows FTP file server
is probably the issue.

T wrote:
On 12/30/2016 04:18 PM, Paul wrote:
T wrote:
On 12/30/2016 01:17 PM, Paul wrote:
T wrote:
Hi All,

I have noticed that Cobian Backup to and FTP server can create files
with read only attributes (644). But neither Widows Explorer or
Cobian
can delete a folder with one of these files in it. This is clearly a
short coming on Windows 7's part and I don't think M$ will ever
address the issue, so ...

To cope with it, I created a cron job to go off at 23:00 to
change the users' ftp directory permissions back to read write
(755).

etc/crontab

# Clean out the read onlys from folks backing up with ftp (Cobian can
# only delete 755 files and chokes on 644 files
05 23 * * * root chmod -R 755 /home/user1/ftp
10 23 * * * root chmod -R 755 /home/user2/ftp
15 23 * * * root chmod -R 755 /home/user3/ftp
20 23 * * * root chmod -R 755 /home/user4/ftp


Problem solved.

-T


I tried testing Cobian, and as a test case, asked
it to back up all of C: .

Based on the permissions problems, are you actually
using it for that, or just for user folders ?

I didn't seem to have a problem with my FTP server.
I installed Filezilla as 127.0.0.1 on the same VM,
so all the testing could be done on one VM to start.
And the setup of FTP didn't present a problem. It
seemed to be working.

Based on the method it appears to be using, it
doesn't look like an Alternate Stream would be
preserved.

Paul

What are you using for an ftp server?

And, what are you using to manipulate your files
from Windows?

Here is a test, copy your appdata/mozilla folder
to an ftp location. Make sure it contains a
folder called "storage". then see if you can delete
the "Mozilla" folder.

Filezilla was the Windows FTP server, so I could
do all the testing in a single VM. My file server
is at 127.0.0.1 . The FTP directory for Filezilla
was FAT32 (as nothing on the source is big enough
to hit the FAT32 file limit).

Cobian seemed to have problems with the usual stuff
you would have problems copying as Administrator.

If it was using VSS, it was hard to tell.

As for your comment about backup software in general,
yes, you can find *lots* of backup programs which will
back up everything on C: , including proper handling
of Junction Points, permissions, ownership, Alternate
Streams, Hard Links, and so on. And storage is to an
image in a proprietary format. In some cases, with
export capability to VHD (another kind of image,
which can be opened by more applications including 7ZIP).

And if you really needed a file-by-file backup method,
you'd try Retrospect (Dantz/EMC, not sure who owns it now).
That started far enough back, that it's an expert at
driving tape drives. But did eventually move to supporting
hard drive backups. I used that to automate backups
on 20 partitions on a Macintosh. And also used it on
a PC for someone else.

It's not much of a backup application if it cannot
conquer permissions. I shouldn't have to launch the
thing as SYSTEM to get it to work. And if I did,
I shudder to think what permissions it would stamp
the files with on a restore.

If you're going to do stuff like that, you might want
to back up the permission bits on the file system
with icacls (to a text file) for safe keeping. That
will allow you to restore the permissions, if your backup/restore
method isn't doing a good job.

icacls d:\ /save ntfsDdrive.txt /t /c

icacls d:\ /restore ntfsDdrive.txt

I suppose, in this case, you don't even need a restore
function, as the files in question are "just sitting there".
But, because Cobian claims to support Differential, using
the automation covers cases where features like that
are being used.

HTH,
Paul

The difference between and Linux and a Windows FTP file server
is probably the issue.

No, Cobian was having trouble *reading* files for backup.
The account launching it was a member of administrators group.

The test system was a Win10 VM. To make sure Cobian
was challenged. I could have used Win7, but I doubt the
outcome would be all that different, as the permission
issues would be the same.

I can understand it failing to copy pagefile.sys. But it
was also missing a lot of smaller files, and I had to stop
the backup because the log was becoming a blizzard.

Paul

On 12/30/2016 07:51 PM, Paul wrote:
T wrote:
On 12/30/2016 04:18 PM, Paul wrote:
T wrote:
On 12/30/2016 01:17 PM, Paul wrote:
T wrote:
Hi All,

I have noticed that Cobian Backup to and FTP server can create files
with read only attributes (644). But neither Widows Explorer or
Cobian
can delete a folder with one of these files in it. This is clearly a
short coming on Windows 7's part and I don't think M$ will ever
address the issue, so ...

To cope with it, I created a cron job to go off at 23:00 to
change the users' ftp directory permissions back to read write
(755).

etc/crontab

# Clean out the read onlys from folks backing up with ftp (Cobian can
# only delete 755 files and chokes on 644 files
05 23 * * * root chmod -R 755 /home/user1/ftp
10 23 * * * root chmod -R 755 /home/user2/ftp
15 23 * * * root chmod -R 755 /home/user3/ftp
20 23 * * * root chmod -R 755 /home/user4/ftp


Problem solved.

-T


I tried testing Cobian, and as a test case, asked
it to back up all of C: .

Based on the permissions problems, are you actually
using it for that, or just for user folders ?

I didn't seem to have a problem with my FTP server.
I installed Filezilla as 127.0.0.1 on the same VM,
so all the testing could be done on one VM to start.
And the setup of FTP didn't present a problem. It
seemed to be working.

Based on the method it appears to be using, it
doesn't look like an Alternate Stream would be
preserved.

Paul

What are you using for an ftp server?

And, what are you using to manipulate your files
from Windows?

Here is a test, copy your appdata/mozilla folder
to an ftp location. Make sure it contains a
folder called "storage". then see if you can delete
the "Mozilla" folder.

Filezilla was the Windows FTP server, so I could
do all the testing in a single VM. My file server
is at 127.0.0.1 . The FTP directory for Filezilla
was FAT32 (as nothing on the source is big enough
to hit the FAT32 file limit).

Cobian seemed to have problems with the usual stuff
you would have problems copying as Administrator.

If it was using VSS, it was hard to tell.

As for your comment about backup software in general,
yes, you can find *lots* of backup programs which will
back up everything on C: , including proper handling
of Junction Points, permissions, ownership, Alternate
Streams, Hard Links, and so on. And storage is to an
image in a proprietary format. In some cases, with
export capability to VHD (another kind of image,
which can be opened by more applications including 7ZIP).

And if you really needed a file-by-file backup method,
you'd try Retrospect (Dantz/EMC, not sure who owns it now).
That started far enough back, that it's an expert at
driving tape drives. But did eventually move to supporting
hard drive backups. I used that to automate backups
on 20 partitions on a Macintosh. And also used it on
a PC for someone else.

It's not much of a backup application if it cannot
conquer permissions. I shouldn't have to launch the
thing as SYSTEM to get it to work. And if I did,
I shudder to think what permissions it would stamp
the files with on a restore.

If you're going to do stuff like that, you might want
to back up the permission bits on the file system
with icacls (to a text file) for safe keeping. That
will allow you to restore the permissions, if your backup/restore
method isn't doing a good job.

icacls d:\ /save ntfsDdrive.txt /t /c

icacls d:\ /restore ntfsDdrive.txt

I suppose, in this case, you don't even need a restore
function, as the files in question are "just sitting there".
But, because Cobian claims to support Differential, using
the automation covers cases where features like that
are being used.

HTH,
Paul

The difference between and Linux and a Windows FTP file server
is probably the issue.

No, Cobian was having trouble *reading* files for backup.
The account launching it was a member of administrators group.

The test system was a Win10 VM. To make sure Cobian
was challenged. I could have used Win7, but I doubt the
outcome would be all that different, as the permission
issues would be the same.

I can understand it failing to copy pagefile.sys. But it
was also missing a lot of smaller files, and I had to stop
the backup because the log was becoming a blizzard.

Paul

Oh yes. Just pick out what data files you want backed up.
Forget the system stuff.