Front page

Re: Error when trying to backup to an external NTFS hard drive mounted via autofs

b327a8a9724d4feda51cd2f49a07d1e8
SCALLION CELEBRATE RETOUCH

From: Laurence Perkins <lperkins@openeye.net>
Date: Mon, 25 Apr 2016 09:44:19 -0700

   Message-ID: <20160425094542.Horde.1TxjoSCZdA7L2ysCn21riy5@htjn.suhail.u
   berspace.de>On Mon, 2016-04-25 at 04:00 -0700, obnam-support-request@obnam.org
   wrote:
   > 
   > > On Tue, Apr 12, 2016 at 09:29:06PM -0400, Ben Boeckel wrote:
   > >> You cannot chmod things (meaningfully) on NTFS. I'd recommend
   > using a
   > >> different filesystem (ext4 has been working beautifully here, but
   > I'm
   > >> sure others have different opinions).
   > >
   > > Hmmm. Obnam uses chmod to set the permissions of files it writes to
   > > the backup repository to 0600 (dirs 0700), i.e., so that only the
   > > owner can read and write them. This is an extra precaution and any
   > > errors about it not being possibly could arguably be ignored,
   > > allowing NTFS to be used for a backup repository.
   > >
   > > Opinions?
   > If you can somehow figure out what FS we're using: Sounds good.
   > Or, if that's somewhat difficult, we could have a generic option
   > for  
   > all FS that don't support permissons... like '--use-lame-fs' or sth  
   > like that...
   > 
   > jan
   > 
   
   Having a way to set what, if any permissions Obnam will use on the
   repository would be useful.  Currently for my shared repositories that
   are backed up over ssh with different user accounts I have to hack that
   line in all the involved clients to leave the group permissions alone. 
   
   Since I seem to be the only one doing that I haven't worried about it,
   but if people want to use NTFS as well it presents an opportunity to
   dispose of a pair of avian creatures with a solitary projectile...
   
   LMP
   
   _______________________________________________
   obnam-support mailing list
   obnam-support@obnam.org
   http://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/obnam-support-obnam.org
From: Lars Wirzenius <liw@liw.fi>
Date: Sat, 16 Jul 2016 11:31:15 +0300

   Slowly working through my backlog of Obnam mails, so I'm quoting this
   whole mail.
   
   On Mon, Apr 25, 2016 at 09:44:19AM -0700, Laurence Perkins wrote:
   > Message-ID: <20160425094542.Horde.1TxjoSCZdA7L2ysCn21riy5@htjn.suhail.u
   > berspace.de>On Mon, 2016-04-25 at 04:00 -0700, obnam-support-request@obnam.org
   > wrote:
   > > 
   > > > On Tue, Apr 12, 2016 at 09:29:06PM -0400, Ben Boeckel wrote:
   > > >> You cannot chmod things (meaningfully) on NTFS. I'd recommend
   > > using a
   > > >> different filesystem (ext4 has been working beautifully here, but
   > > I'm
   > > >> sure others have different opinions).
   > > >
   > > > Hmmm. Obnam uses chmod to set the permissions of files it writes to
   > > > the backup repository to 0600 (dirs 0700), i.e., so that only the
   > > > owner can read and write them. This is an extra precaution and any
   > > > errors about it not being possibly could arguably be ignored,
   > > > allowing NTFS to be used for a backup repository.
   > > >
   > > > Opinions?
   > > If you can somehow figure out what FS we're using: Sounds good.
   > > Or, if that's somewhat difficult, we could have a generic option
   > > for  
   > > all FS that don't support permissons... like '--use-lame-fs' or sth  
   > > like that...
   > > 
   > > jan
   > > 
   > 
   > Having a way to set what, if any permissions Obnam will use on the
   > repository would be useful.  Currently for my shared repositories that
   > are backed up over ssh with different user accounts I have to hack that
   > line in all the involved clients to leave the group permissions alone. 
   > 
   > Since I seem to be the only one doing that I haven't worried about it,
   > but if people want to use NTFS as well it presents an opportunity to
   > dispose of a pair of avian creatures with a solitary projectile...
   
   I'd be happy to consider a patch that makes Obnam try to chmod files
   and dirs it creates in the repository, but not fail if the chmod
   fails. The failure should be logged as a warning and subsequently the
   chmod shouldn't be tried anymore.
   
   Would that make sense to others?