Hello.
I have NC installation running, but it seems that when I try to update with:
root@ncp:~# ncp-update-nc
BTRFS not supported
I cannot find a reason why is btrfs anyway āspecialā that it is not supported. Can someone give me or point me to an answer?
How those installations should be updated?
Hello,
First, without any clue about your system or config, how do you expect to get helped !
As up today, BTRFS is mainly unstable on every distro with a kernel below 5.0.
Also, with kernel 5.0, if you have some kind of raid, you may experience āstarbgeā bug like write holesā¦
this doesnt mean that itās compatible. you claim to have nc installed. but if itās not based upon ncp you wonāt find any of the nc-commands working for you-
I would like an answer, so this is more like āhelp me find an answerā. 
So Iām not sure how it would help as Iām asking about filesystem support, but here: I have Armbian running on BananaPi with nextcloud installed via nextcloudpi.
Iām btrfs user for 5+ years now and no major issues so far. Thatās one of the reasons why Iām looking for an answer. Filesystem tend to have bugs - some of them have more bugs, some less, but why one is supported and the other is not? What if Iām using bcachefs for my setup? Or somebrandnewuntestedfs? Thatās a users choise and if there is no valid arguments except ābecause it ate my data!!!ā (like ābecause weāre using some feature that doesnt work in btrfsā) it should just work (maybe with --yes-i-know-i-m-using-btrfs option).
It is, ncp-update (and others) works fine.
Thereās even a line ncp-update-nc:
[[ ā$(stat -fc%T ā$BASEDIRā)ā == ābtrfsā ]] && { echo āBTRFS not supportedā ; exit 1; }
It seems Iāve found an answer (well, a bit weird, but it seems to be related to āBTRFS not supportedā message):
It seems NCP supports btrfs only for ncdata. if the whole drive and OS is on btrfs it does not (yet) support that.
You will have to update using NCās native updater to upgrade NC.
What do you mean by āNCP supports btrfs only for ncdataā?
Iāve commented out the btrfs check in ncp-update-nc and it ājust workedā as on any other fs. So
one question solved - you can comment it out and āon your own riskā update even on btrfs.
[I can consider this as āsecond question solvedā]
But still the first question is without an answer:
Good to know.
Did you see https://docs.nextcloudpi.com/en/configuration-reference/#backups ?
NCP supports btrfs (and snapshots) when you let ncp format the drive and move the data to it with nc-datadir.
Maybe @nachoparker can enlighten us why this check is included.
You canāt delete a BTRFS subvolume with a rm command. Since in BTRFS ncdata is a subvolume, the script needs to be adapted so I added that check until that happens.
This only affects when we have / in BTRFS. Most common setup has / in ext.
It should be an easy fix. PRs are welcome.
My point was maybe not clear enough. I am not saying btrf is not fit for regular use. But:
Using btrf in a raid 60 right now is clearly Mark as unstable by the dev team.
All my server are raid 60 based, in clustering mode. I have already experience a āwrite holeā bug, witch cascaded through a whole cluster.
It was more than my tech capacities. Had to reach to a data recovery us based company who charged us a lot.
So, when someone ask about btrf, I use to give that answer.
Sorry if it was not really accordingly for your scope of used.
Over the 20+ server I had today, only one is still in raid60 btrf, kind of ālabā server
@nachoparker This I dont understand - I have btrfs on / and without ncdata subvol. I would even say that without any subvols except those Iāve created.
@stratege1401 One should always remember that raid is not a backup.
1 Like
YOU ARE ABSOLUTELY RIGHT !
but it could if done in raid60 clustering over iscsi, with de-localized units.
Funny, I have the same setup and did the same mistake when choosing to have btrfs on the SSD. 
After all, I was following some recommendations that said, btrfs is better for backup purposesā¦
Now, NC is running fine but sometimes I find the Banana locked up with some file system error message.
I checked some logs and came across a log message saying
swap file has holes
My search revealed that btrfs does not support swap files.
And thatās when I stopped due to time reasons.
Since, I have been thinking of repartitioning the SSD to add an ext FS where the swap could be placed on - but that doesnāt seem easy also.
If I understood right, the ānot supportedā issue is due to a wrong call how the backup subvolume is removed at the end of the upgrade process. If there is more about it, maybe the separate ext would also help in this case?
1 Like
disable swap and enable zram
if you use nc-datadir to a BTRFS volume then the datadir will be placed in a subvolume so it can be snapshotted
Is there a way to check and confirm this (on my device)?
nc-info should provide that or
to list subvolumes you can also use
sudo btrfs subvolume list /path/to/ncdata
But I didnt make any [checks his backups] mistakes. As I said Iām using btrfs and know itās pros and cons. Iām using zram swap, so no swapfile issues.
@nachoparker So maybe check if ncdata is a subvol and if not just support normal update? It seems the check is trival: bash - How to test if location is a btrfs subvolume? - Stack Overflow (or just add a switch --i-know-what-i-m-doing)
I invite you to study the problem and provide a solution for all the community. The idea is that each person conttributes with improving a particular itch and NCP gets better everyday.
I am using a different setup so I am not particularly interested in solving this but I would be happy to review and accept a PR. 
1 Like
Hi nachoparker,
I have installed Debian on a btrfs partition and then used NCP to install nextcloud. Accordingly, I ran into the same error message when trying to upgrade Nextcloud via NCP. I do have the same setup:
- System and Nextcloud is installed on a btrfs partition, with / as btrfs subvolume.
- This is the ONLY subvolume on the system partition, besides others I created. (But this should not affect the update process.)
- I have moved the ncdata directory to an external SSD using
nc-datadir.sh. The partition on the external SSD was formatted as btrfs bync-datadir.sh. Therewith, the datadir does not reside on the same partition than the Nextcloud program.
I would like to try and find a small fix for this.
I do have a small request for you: I would like to make sure, that I properly understand your reason for blocking the NC Update/Upgrade on a system, where NC resides on a btrfs partition.
The reason I understand as follows:
- On line 114 of
ncp-update-ncthe commandrm -rf "$BASEDIR"/nextcloudwill fail, if the datadir still is under/var/www/nextcloud/data, since a btrfs subvolume cannot be removed by rm. - So you abort the upgrade process if the root partition / tested in line 32 with the expression
[[ "$(stat -fc%T "$BASEDIR")" == "btrfs" ]]reports as true.
My thoughts run as follows:
- As I understand, the btrfs subvolume underneath a directory, which is removed, is NOT removed itself. Instead, all files and directories in it are removed. Essentially, the btrfs subvolume is empty after the
rmcommand. - If now a new directory is created, where the still existing btrfs subvolume would be a subdirectory beneath, this particular subdirectory is not newly created. Instead, the existing btrfs subdirectory is used! So, when you use in line 115 the command
mv "$BASEDIR"/nextcloud-old "$BASEDIR"/nextcloud, this would again populate the still existing btrfs subdirectory. There will be some error messages, but the command should continue.
Are these thoughts correct, or do I have made a mistake?
Best regards
LittleAlf
Your diagnosis is basically correct, I might be forgetting some detail.
On rm it will fail with Operation not permitted, so we have to do btrfs subvolume delete in the BTRFS case, which will remove the subvolume.
If you start digging into this it will be pretty obvious 