Re: A user cannot remove his readonly snapshots?!

2017-09-18 Thread Austin S. Hemmelgarn 

On 2017-09-16 10:28, Ulli Horlacher wrote:

On Sat 2017-09-16 (13:47), Kai Krakow wrote:


Or you do "btrfs device stats .", it shows the associated device(s).


tux@xerus:/test/tux/zz: btrfs device stats .
ERROR: getting dev info for devstats failed: Operation not permitted

Not possible for a normal user.

`btrfs fi show` should be possible for a normal user, and that also 
lists devices.  Alternatively, you can check /sys/fs/btrfs and correlate 
UUID's (possibly easier programmatically than analyzing regular output).


--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: A user cannot remove his readonly snapshots?!

2017-09-18 Thread Austin S. Hemmelgarn 

On 2017-09-15 15:32, Ulli Horlacher wrote:

On Fri 2017-09-15 (13:08), Austin S. Hemmelgarn wrote:

On 2017-09-15 12:37, Ulli Horlacher wrote:


I have my btrfs filesystem mounted with option user_subvol_rm_allowed
tux@xerus: btrfs subvolume delete /test/tux/zz/.snapshot/2017-09-15_1824.test
Delete subvolume (no-commit): '/test/tux/zz/.snapshot/2017-09-15_1824.test'
ERROR: cannot delete '/test/tux/zz/.snapshot/2017-09-15_1824.test': Read-only 
file system

root can delete this snapshot, but not the user. Why?



Add 'user_subvol_rm' to the mount options and try again.


root@xerus:~# mount -vo user_subvol_rm /dev/sdd4 /test
mount: wrong fs type, bad option, bad superblock on /dev/sdd4,
missing codepage or helper program, or other error

In some cases useful info is found in syslog - try
dmesg | tail or so.

root@xerus:~# dmesg | tail -2
[1514588.018991] BTRFS info (device sdd4): unrecognized mount option 
'user_subvol_rm'
[1514588.028430] BTRFS: open_ctree failed

user_subvol_rm is not listed on
https://btrfs.wiki.kernel.org/index.php/Mount_options

Did you mean user_subvol_rm_allowed?

Yes, that's what I meant, sorry about the confusion.

I have already used this option, without success. See above.

I missed that, sorry.

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: A user cannot remove his readonly snapshots?!

2017-09-16 Thread Ulli Horlacher 
On Sat 2017-09-16 (13:47), Kai Krakow wrote:

> Or you do "btrfs device stats .", it shows the associated device(s).

tux@xerus:/test/tux/zz: btrfs device stats .
ERROR: getting dev info for devstats failed: Operation not permitted

Not possible for a normal user.


-- 
Ullrich Horlacher  Server und Virtualisierung
Rechenzentrum TIK 
Universitaet Stuttgart E-Mail: horlac...@tik.uni-stuttgart.de
Allmandring 30aTel:++49-711-68565868
70569 Stuttgart (Germany)  WWW:http://www.tik.uni-stuttgart.de/
REF:<20170916134748.00a7e...@jupiter.sol.kaishome.de>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: A user cannot remove his readonly snapshots?!

2017-09-16 Thread Kai Krakow 
Am Sat, 16 Sep 2017 09:36:33 +0200
schrieb Ulli Horlacher :

> On Sat 2017-09-16 (01:22), Kai Krakow wrote:
> 
> > > tux@xerus:/test/tux/zz/.snapshot: btrfs subvolume delete
> > > 2017-09-15_1859.test Delete subvolume (no-commit):
> > > '/test/tux/zz/.snapshot/2017-09-15_1859.test' ERROR: cannot delete
> > > '/test/tux/zz/.snapshot/2017-09-15_1859.test': Read-only file
> > > system  
> > 
> > See "man mount" in section btrfs mount options: There is a mount
> > option to allow normal user to delete snapshots.  
> 
> As I wrote first: "I have mounted with option user_subvol_rm_allowed"
> 
> tux@xerus:/test/tux/zz/.snapshot: mount | grep /test
> /dev/sdd4 on /test type btrfs
> (rw,relatime,space_cache,user_subvol_rm_allowed,subvolid=5,subvol=/)
> 
> This does not help. A user cannot remove a readonly snapshot he just
> has created.

Yes, sorry, I only later discovered the other posts.


-- 
Regards,
Kai

Replies to list-only preferred.

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: A user cannot remove his readonly snapshots?!

2017-09-16 Thread Marat Khalili 

On 16/09/17 13:19, Ulli Horlacher wrote:

How do I know the btrfs filesystem for a given subvolume?
Do I really have to manually test the diretory path upwards?


It was discussed recently: the answer is, unfortunately, yes, until 
someone patches df to do it for us. You can do it more or less 
efficiently by analyzing /proc/mounts .


--

With Best Regards,
Marat Khalili

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: A user cannot remove his readonly snapshots?!

2017-09-16 Thread Ulli Horlacher 
On Sat 2017-09-16 (10:10), Goffredo Baroncelli wrote:
> On 09/15/2017 06:37 PM, Ulli Horlacher wrote:

> > I have my btrfs filesystem mounted with option user_subvol_rm_allowed
> 
> You should change the "ro" property to false before deleting it
> 
>   btrfs property set /test/tux/zz/.snapshot/2017-09-15_1824.test ro false

Still one problem is left: 
How can I test a subvolume for the mount option user_subvol_rm_allowed?
df only works for the root subvolume:

root@xerus:/test/tux# df -T .
Filesystem Type  1K-blocks   Used Available Use% Mounted on
/dev/sdd4  btrfs  54524928 103372  52326324   1% /test

root@xerus:/test/tux# df -T zz
Filesystem Type 1K-blocks   Used Available Use% Mounted on
-  - 54524928 103372  52326324   1% /test/tux/zz

root@xerus:/test/tux# mount | grep /test
/dev/sdd4 on /test type btrfs 
(rw,relatime,space_cache,user_subvol_rm_allowed,subvolid=5,subvol=/)

How do I know the btrfs filesystem for a given subvolume?
Do I really have to manually test the diretory path upwards?


-- 
Ullrich Horlacher  Server und Virtualisierung
Rechenzentrum TIK 
Universitaet Stuttgart E-Mail: horlac...@tik.uni-stuttgart.de
Allmandring 30aTel:++49-711-68565868
70569 Stuttgart (Germany)  WWW:http://www.tik.uni-stuttgart.de/
REF:
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: A user cannot remove his readonly snapshots?!

2017-09-16 Thread Ulli Horlacher 
On Sat 2017-09-16 (11:04), Goffredo Baroncelli wrote:

> In the past I proposed to allow an ordinary user to remove an *empty* 
> subvolume with a simple rmdir (if he has the permissions). This would solve 
> this kind of problem.
> or to relax the check around "btrfs sub del", so an user can remove an 
> _empty_ subvolume

This would help a lot!
Where can I sign this petition? :-)

-- 
Ullrich Horlacher  Server und Virtualisierung
Rechenzentrum TIK 
Universitaet Stuttgart E-Mail: horlac...@tik.uni-stuttgart.de
Allmandring 30aTel:++49-711-68565868
70569 Stuttgart (Germany)  WWW:http://www.tik.uni-stuttgart.de/
REF:<2d343791-7b32-bd53-a03d-a5b26465d...@libero.it>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: A user cannot remove his readonly snapshots?!

2017-09-16 Thread Peter Grandi 
[ ... ]

> I can delete normal subvolumes but not the readonly snapshots:

It is because of ordinary permissions for both subvolumes and
snapshots:

  tree$  btrfs sub create /fs/sda7/sub
  Create subvolume '/fs/sda7/sub'

  tree$  chmod a-w /fs/sda7/sub
  tree$  btrfs sub del /fs/sda7/sub
  Delete subvolume (no-commit): '/fs/sda7/sub'
  ERROR: cannot delete '/fs/sda7/sub': Permission denied

  tree$  chmod u+w /fs/sda7/sub
  tree$  btrfs sub del /fs/sda7/sub
  Delete subvolume (no-commit): '/fs/sda7/sub'

It is however possible to remove an ordinary read-only
directory, *as long as its parent directory is not read-only
too*:

  tree$  mkdir /fs/sda7/sub
  tree$  chmod a-w /fs/sda7/sub
  tree$  rmdir /fs/sda7/sub; echo $?
  0

IIRC this came up before, and the reason for the difference is
that a subvolume root directory is "special" because its '..'
entry points to itself (inode 256), that is if it is read-only
its parent directory (itself) then is read-only too.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: A user cannot remove his readonly snapshots?!

2017-09-16 Thread Goffredo Baroncelli 
On 09/16/2017 01:22 AM, Kai Krakow wrote:
> Am Sat, 16 Sep 2017 00:02:01 +0200
> schrieb Ulli Horlacher :
> 
>> On Fri 2017-09-15 (23:44), Ulli Horlacher wrote:
[...]
> 
> See "man mount" in section btrfs mount options: There is a mount option
> to allow normal user to delete snapshots. But this is said to has
> security implication I cannot currently tell. Maybe someone else knows.

"btrfs sub del" removes a subvolume independently by its contents: it doesn't 
check the subvolume files/directories and their permission/ownership. 

This is different from a "rm -rf", which (e.g.) can't delete a directory owned 
by a different user with files

ghigo@venice:/tmp$ mkdir d
ghigo@venice:/tmp$ mkdir d/d
ghigo@venice:/tmp$ touch d/d/f
ghigo@venice:/tmp$ sudo chown nobody d/d
ghigo@venice:/tmp$ rm -rf d
rm: cannot remove 'd/d/f': Permission denied

In the past I proposed to allow an ordinary user to remove an *empty* subvolume 
with a simple rmdir (if he has the permissions). This would solve this kind of 
problem.

https://www.spinics.net/lists/linux-btrfs/msg06499.html

or to relax the check around "btrfs sub del", so an user can remove an _empty_ 
subvolume

https://www.spinics.net/lists/linux-btrfs/msg06522.html

> 
> 
BR
G.Baroncelli

-- 
gpg @keyserver.linux.it: Goffredo Baroncelli 
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: A user cannot remove his readonly snapshots?!

2017-09-16 Thread Ulli Horlacher 
On Sat 2017-09-16 (10:10), Goffredo Baroncelli wrote:

> > tux@xerus: btrfs subvolume snapshot -r /test/tux/zz 
> > /test/tux/zz/.snapshot/2017-09-15_1824.test
> > tux@xerus: btrfs subvolume delete 
> > /test/tux/zz/.snapshot/2017-09-15_1824.test
> > Delete subvolume (no-commit): '/test/tux/zz/.snapshot/2017-09-15_1824.test'
> > ERROR: cannot delete '/test/tux/zz/.snapshot/2017-09-15_1824.test': 
> > Read-only file system
> > 
> > root can delete this snapshot, but not the user. Why?
> 
> You should change the "ro" property to false before deleting it
> 
>   btrfs property set /test/tux/zz/.snapshot/2017-09-15_1824.test ro false

tux@xerus: btrfs property set /test/tux/zz/.snapshot/2017-09-15_1824.test ro 
false
tux@xerus: btrfs subvolume delete /test/tux/zz/.snapshot/2017-09-15_1824.test
Delete subvolume (no-commit): '/test/tux/zz/.snapshot/2017-09-15_1824.test'

That's it! It works (now)! Great! Thanks!

Up to now I was thinking about a sudo solution, but this is not necessary
any more. Less complex solutions are always better :-)

I *love* this mailing list :-)

-- 
Ullrich Horlacher  Server und Virtualisierung
Rechenzentrum TIK 
Universitaet Stuttgart E-Mail: horlac...@tik.uni-stuttgart.de
Allmandring 30aTel:++49-711-68565868
70569 Stuttgart (Germany)  WWW:http://www.tik.uni-stuttgart.de/
REF:
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: A user cannot remove his readonly snapshots?!

2017-09-16 Thread Goffredo Baroncelli 
On 09/15/2017 06:37 PM, Ulli Horlacher wrote:
> I have my btrfs filesystem mounted with option user_subvol_rm_allowed
> 
> tux@xerus: btrfs --version
> btrfs-progs v4.4
> 
> tux@xerus: uname -a
> Linux xerus 4.4.0-93-generic #116-Ubuntu SMP Fri Aug 11 21:17:51 UTC 2017 
> x86_64 x86_64 x86_64 GNU/Linux
> 
> tux@xerus: id
> uid=1000(tux) gid=100(users) groups=100(users)
> 
> tux@xerus: btrfs subvolume snapshot -r /test/tux/zz 
> /test/tux/zz/.snapshot/2017-09-15_1824.test
> tux@xerus: btrfs subvolume delete /test/tux/zz/.snapshot/2017-09-15_1824.test
> Delete subvolume (no-commit): '/test/tux/zz/.snapshot/2017-09-15_1824.test'
> ERROR: cannot delete '/test/tux/zz/.snapshot/2017-09-15_1824.test': Read-only 
> file system
> 
> root can delete this snapshot, but not the user. Why?

You should change the "ro" property to false before deleting it

btrfs property set /test/tux/zz/.snapshot/2017-09-15_1824.test ro false


BR
G.Baroncelli

-- 
gpg @keyserver.linux.it: Goffredo Baroncelli 
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: A user cannot remove his readonly snapshots?!

2017-09-16 Thread Ulli Horlacher 
On Sat 2017-09-16 (01:22), Kai Krakow wrote:

> > tux@xerus:/test/tux/zz/.snapshot: btrfs subvolume delete
> > 2017-09-15_1859.test Delete subvolume (no-commit):
> > '/test/tux/zz/.snapshot/2017-09-15_1859.test' ERROR: cannot delete
> > '/test/tux/zz/.snapshot/2017-09-15_1859.test': Read-only file system
> 
> See "man mount" in section btrfs mount options: There is a mount option
> to allow normal user to delete snapshots.

As I wrote first: "I have mounted with option user_subvol_rm_allowed"

tux@xerus:/test/tux/zz/.snapshot: mount | grep /test
/dev/sdd4 on /test type btrfs 
(rw,relatime,space_cache,user_subvol_rm_allowed,subvolid=5,subvol=/)

This does not help. A user cannot remove a readonly snapshot he just has
created.


-- 
Ullrich Horlacher  Server und Virtualisierung
Rechenzentrum TIK 
Universitaet Stuttgart E-Mail: horlac...@tik.uni-stuttgart.de
Allmandring 30aTel:++49-711-68565868
70569 Stuttgart (Germany)  WWW:http://www.tik.uni-stuttgart.de/
REF:<20170916012248.0870f...@jupiter.sol.kaishome.de>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: A user cannot remove his readonly snapshots?!

2017-09-15 Thread Kai Krakow 
Am Sat, 16 Sep 2017 00:02:01 +0200
schrieb Ulli Horlacher :

> On Fri 2017-09-15 (23:44), Ulli Horlacher wrote:
> > On Fri 2017-09-15 (22:07), Peter Grandi wrote:
> >   
>  [...]  
> > > 
> > > Ordinary permissions still apply both to 'create' and 'delete':  
> > 
> > My user tux is the owner of the snapshot directory, because he has
> > created it!  
> 
> I can delete normal subvolumes but not the readonly snapshots:
> 
> tux@xerus:/test/tux/zz/.snapshot: btrfs subvolume create test
> Create subvolume './test'
> 
> tux@xerus:/test/tux/zz/.snapshot: ll
> drwxr-xr-x  tux  users- 2017-09-15 18:22:26
> 2017-09-15_1822.test drwxr-xr-x  tux  users- 2017-09-15
> 18:22:26 2017-09-15_1824.test drwxr-xr-x  tux  users-
> 2017-09-15 18:57:39 2017-09-15_1859.test drwxr-xr-x  tux
> users- 2017-09-15 23:58:51 test
> 
> tux@xerus:/test/tux/zz/.snapshot: btrfs subvolume delete test
> Delete subvolume (no-commit): '/test/tux/zz/.snapshot/test'
> 
> tux@xerus:/test/tux/zz/.snapshot: btrfs subvolume delete
> 2017-09-15_1859.test Delete subvolume (no-commit):
> '/test/tux/zz/.snapshot/2017-09-15_1859.test' ERROR: cannot delete
> '/test/tux/zz/.snapshot/2017-09-15_1859.test': Read-only file system

See "man mount" in section btrfs mount options: There is a mount option
to allow normal user to delete snapshots. But this is said to has
security implication I cannot currently tell. Maybe someone else knows.


-- 
Regards,
Kai

Replies to list-only preferred.

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: A user cannot remove his readonly snapshots?!

2017-09-15 Thread Ulli Horlacher 
On Fri 2017-09-15 (23:44), Ulli Horlacher wrote:
> On Fri 2017-09-15 (22:07), Peter Grandi wrote:
> 
> > >  [ ... ] mounted with option user_subvol_rm_allowed [ ... ]
> > > root can delete this snapshot, but not the user. Why? [ ... ]
> > 
> > Ordinary permissions still apply both to 'create' and 'delete':
> 
> My user tux is the owner of the snapshot directory, because he has created it!

I can delete normal subvolumes but not the readonly snapshots:

tux@xerus:/test/tux/zz/.snapshot: btrfs subvolume create test
Create subvolume './test'

tux@xerus:/test/tux/zz/.snapshot: ll
drwxr-xr-x  tux  users- 2017-09-15 18:22:26 2017-09-15_1822.test
drwxr-xr-x  tux  users- 2017-09-15 18:22:26 2017-09-15_1824.test
drwxr-xr-x  tux  users- 2017-09-15 18:57:39 2017-09-15_1859.test
drwxr-xr-x  tux  users- 2017-09-15 23:58:51 test

tux@xerus:/test/tux/zz/.snapshot: btrfs subvolume delete test
Delete subvolume (no-commit): '/test/tux/zz/.snapshot/test'

tux@xerus:/test/tux/zz/.snapshot: btrfs subvolume delete 2017-09-15_1859.test
Delete subvolume (no-commit): '/test/tux/zz/.snapshot/2017-09-15_1859.test'
ERROR: cannot delete '/test/tux/zz/.snapshot/2017-09-15_1859.test': Read-only 
file system

-- 
Ullrich Horlacher  Server und Virtualisierung
Rechenzentrum TIK 
Universitaet Stuttgart E-Mail: horlac...@tik.uni-stuttgart.de
Allmandring 30aTel:++49-711-68565868
70569 Stuttgart (Germany)  WWW:http://www.tik.uni-stuttgart.de/
REF:<20170915214434.gg32...@rus.uni-stuttgart.de>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: A user cannot remove his readonly snapshots?!

2017-09-15 Thread Ulli Horlacher 
On Fri 2017-09-15 (22:07), Peter Grandi wrote:
> >  [ ... ] mounted with option user_subvol_rm_allowed [ ... ]
> > root can delete this snapshot, but not the user. Why? [ ... ]
> 
> Ordinary permissions still apply both to 'create' and 'delete':

My user tux is the owner of the snapshot directory, because he has created it!

tux@xerus:/test/tux/zz: id
uid=1000(tux) gid=100(users) groups=100(users)

tux@xerus:/test/tux/zz: ll .snapshot/
drwxr-xr-x  tux  users- 2017-09-15 18:22:26 
.snapshot/2017-09-15_1822.test
drwxr-xr-x  tux  users- 2017-09-15 18:22:26 
.snapshot/2017-09-15_1824.test
drwxr-xr-x  tux  users- 2017-09-15 18:57:39 
.snapshot/2017-09-15_1859.test

tux@xerus:/test/tux/zz: btrfs subvolume delete .snapshot/2017-09-15_1859.test
Delete subvolume (no-commit): '/test/tux/zz/.snapshot/2017-09-15_1859.test'
ERROR: cannot delete '/test/tux/zz/.snapshot/2017-09-15_1859.test': Read-only 
file system

-- 
Ullrich Horlacher  Server und Virtualisierung
Rechenzentrum TIK 
Universitaet Stuttgart E-Mail: horlac...@tik.uni-stuttgart.de
Allmandring 30aTel:++49-711-68565868
70569 Stuttgart (Germany)  WWW:http://www.tik.uni-stuttgart.de/
REF:<22972.16657.822204.646...@tree.ty.sabi.co.uk>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: A user cannot remove his readonly snapshots?!

2017-09-15 Thread Peter Grandi 
>  [ ... ] mounted with option user_subvol_rm_allowed [ ... ]
> root can delete this snapshot, but not the user. Why? [ ... ]

Ordinary permissions still apply both to 'create' and 'delete':

  tree$  sudo mkdir /fs/sda7/dir
  tree$  btrfs sub create /fs/sda7/dir/sub
  ERROR: cannot access /fs/sda7/dir/sub: Permission denied

  tree$  sudo chmod a+rwx /fs/sda7/dir
  tree$  btrfs sub create /fs/sda7/dir/sub
  Create subvolume '/fs/sda7/dir/sub'

  tree$  btrfs sub delete /fs/sda7/dir/sub
  Delete subvolume (no-commit): '/fs/sda7/dir/sub'
  ERROR: cannot delete '/fs/sda7/dir/sub': Operation not permitted
  tree$  sudo mount -o remount,user_subvol_rm_allowed /fs/sda7
  tree$  btrfs sub delete /fs/sda7/dir/sub
  Delete subvolume (no-commit): '/fs/sda7/dir/sub'

  tree$  btrfs sub create /fs/sda7/dir/sub
  Create subvolume '/fs/sda7/dir/sub'

  tree$  sudo chmod a-w /fs/sda7/dir
  tree$  btrfs sub delete /fs/sda7/dir/sub
  Delete subvolume (no-commit): '/fs/sda7/dir/sub'
  ERROR: cannot delete '/fs/sda7/dir/sub': Permission denied

  tree$  sudo chmod a+w /fs/sda7/dir
  tree$  btrfs sub delete /fs/sda7/dir/sub
  Delete subvolume (no-commit): '/fs/sda7/dir/sub'
  tree$  sudo rmdir /fs/sda7/dir
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: A user cannot remove his readonly snapshots?!

2017-09-15 Thread Ulli Horlacher 
On Fri 2017-09-15 (13:08), Austin S. Hemmelgarn wrote:
> On 2017-09-15 12:37, Ulli Horlacher wrote:
> 
> > I have my btrfs filesystem mounted with option user_subvol_rm_allowed
> > tux@xerus: btrfs subvolume delete 
> > /test/tux/zz/.snapshot/2017-09-15_1824.test
> > Delete subvolume (no-commit): '/test/tux/zz/.snapshot/2017-09-15_1824.test'
> > ERROR: cannot delete '/test/tux/zz/.snapshot/2017-09-15_1824.test': 
> > Read-only file system
> > 
> > root can delete this snapshot, but not the user. Why?
> > 
> 
> Add 'user_subvol_rm' to the mount options and try again.

root@xerus:~# mount -vo user_subvol_rm /dev/sdd4 /test
mount: wrong fs type, bad option, bad superblock on /dev/sdd4,
   missing codepage or helper program, or other error

   In some cases useful info is found in syslog - try
   dmesg | tail or so.

root@xerus:~# dmesg | tail -2
[1514588.018991] BTRFS info (device sdd4): unrecognized mount option 
'user_subvol_rm'
[1514588.028430] BTRFS: open_ctree failed

user_subvol_rm is not listed on
https://btrfs.wiki.kernel.org/index.php/Mount_options

Did you mean user_subvol_rm_allowed?
I have already used this option, without success. See above.


-- 
Ullrich Horlacher  Server und Virtualisierung
Rechenzentrum TIK 
Universitaet Stuttgart E-Mail: horlac...@tik.uni-stuttgart.de
Allmandring 30aTel:++49-711-68565868
70569 Stuttgart (Germany)  WWW:http://www.tik.uni-stuttgart.de/
REF:<38b35e41-313a-1eed-667a-ee3138c81...@gmail.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: A user cannot remove his readonly snapshots?!

2017-09-15 Thread Austin S. Hemmelgarn 

On 2017-09-15 12:37, Ulli Horlacher wrote:

I have my btrfs filesystem mounted with option user_subvol_rm_allowed

tux@xerus: btrfs --version
btrfs-progs v4.4

tux@xerus: uname -a
Linux xerus 4.4.0-93-generic #116-Ubuntu SMP Fri Aug 11 21:17:51 UTC 2017 
x86_64 x86_64 x86_64 GNU/Linux

tux@xerus: id
uid=1000(tux) gid=100(users) groups=100(users)

tux@xerus: btrfs subvolume snapshot -r /test/tux/zz 
/test/tux/zz/.snapshot/2017-09-15_1824.test
tux@xerus: btrfs subvolume delete /test/tux/zz/.snapshot/2017-09-15_1824.test
Delete subvolume (no-commit): '/test/tux/zz/.snapshot/2017-09-15_1824.test'
ERROR: cannot delete '/test/tux/zz/.snapshot/2017-09-15_1824.test': Read-only 
file system

root can delete this snapshot, but not the user. Why?


Add 'user_subvol_rm' to the mount options and try again.

It's because of a poor decision made regarding permissions surrounding 
subvolume operations.  The original argument was to prevent accidental 
data loss (stupid argument, rm -rf is just as bad and nearly as fast on 
most modern systems), and that behavior has never been changed.  In 
fact, I'd advocate using that option on everything, because otherwise 
you have trivial resource exhaustion issues (users can create a resource 
they then can't remove).  Ideally, normal users wouldn't be able to 
create or delete subvolumes unless explicitly allowed (possibly through 
delegation by ownership or something).

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html