Behaviour/Resource Packs — File System Issue
Issue
Behaviour/resource packs are not loaded when run on a Linux machine with `XFS` as the filesystem and the `ftype` flag set to `0`.
We discovered an issue recently where a number of our Linux machines had Bedrock Dedicated Servers which would not load behaviour/resource packs. After some investigation we found the only real difference between machines that did work and machines that didn't were the file system:
- CentOS 7 `ext4`: works
- CentOS 7 `XFS`: works
- Almalinux 8 `ext4`: works
- Almalinux 8 `XFS` with `ftype=1`: works
- Almalinux 8 `XFS` with `ftype=0`: does not work
The flag seems to be purely a metadata structure thing so we are unsure why this would cause an issue.
Unfortunately, changing the flag requires rebuilding the entire filesystem (aka, reinstalling the OS). — This isn't feasible for us so we hope there's a way this can be resolved upstream.
Replication Process
1. For demonstration purposes, let's use a known working one from a public library: https://mcpedl.com/extended-amethyst-add-on/ (though any would work as far as we can tell)
2. Once the files are downloaded, one will be a behaviour pack, and the other will be a resource pack. Let's import both to the client by simply double-clicking them.
3. After that, let's create a new single-player world and under 'Add-Ons', select both.
4. Once created, we can verify in creative that it does work in single-player by simply searching for an amethyst ring: https://i.geri.dev/sQIRTPXwBGj5.png
Now, let's exit out of this world and copy the files into a server.
5. Download the dedicated server files from https://www.minecraft.net/en-us/download/server/bedrock (Apparently only the Beta one is available there currently so we'll use the latest stable instead, `v1.18.31`)
6. Upload the freshly created world folder from `%LocalAppData%\Packages\Microsoft.MinecraftUWP_8wekyb3d8bbwe\LocalState\games\com.mojang\minecraftWorlds` to `./worlds/` on the server and rename it to `Bedrock level`.
7. Start the server directly and attempt to connect.
On a working machine, here is what we'll see:
- Login screen: Shows that we would have to download 0.04 MB to apply the resource pack (see below about the cache) — https://i.geri.dev/vI1nYpMRyzHk.png
- Once logged in, we can search for the amethyst ring without any issues: https://i.geri.dev/2YpxTzICd7fP.png
On a machine that has `XFS` with `ftype=0`, here is what we see:
- Login screen: Shows that we'd only need to download 0.02 MB (see about cache below) — https://i.geri.dev/maxb4yn9SdoA.png
- In-game, we cannot view any new items such as the amethyst ring — https://i.geri.dev/pPaLxrJnyHCi.png
More Information
Additionally, this happens to all players on different devices from further testing.
As for the cache, it looks like if you already connected previously to a world with the exact resource/behaviour packs, it will store it locally so the download screen may not match correctly. As such, we made sure to clear the game's cache through Main Menu ➜ 'Settings' ➜ 'Storage' when possible just so that is not the problem.
We have also tried numerous times to manually install these behaviour packs just in case single player did it incorrectly — though it seems to be doing it perfectly as the `world_resource_packs.json` and `world_behavior_packs.json` seems to always match the data in the packs' `manifest.json` information.
For convenience, we have compiled a ZIP archive of an entire server that has issues when running on a machine with the conditions mentioned above: https://archive.geri.dev/bedrock_test.zip (~73 MB total)
Created Issue:
Behaviour/Resource Packs — File System Issue
Issue
Behaviour/resource packs are not loaded when run on a Linux machine with `XFS` as the filesystem and the `ftype` flag set to `0`.
We discovered an issue recently where a number of our Linux machines had Bedrock Dedicated Servers which would not load behaviour/resource packs. After some investigation we found the only real difference between machines that did work and machines that didn't were the file system:
- CentOS 7 `ext4`: works
- CentOS 7 `XFS`: works
- Almalinux 8 `ext4`: works
- Almalinux 8 `XFS` with `ftype=1`: works
- Almalinux 8 `XFS` with `ftype=0`: does not work
The flag seems to be purely a metadata structure thing so we are unsure why this would cause an issue.
Unfortunately, changing the flag requires rebuilding the entire filesystem (aka, reinstalling the OS). — This isn't feasible for us so we hope there's a way this can be resolved upstream.
—
Replication Process
- For demonstration purposes, let's use a known working one from a public library: https://mcpedl.com/extended-amethyst-add-on/ (though any would work as far as we can tell)
- Once the files are downloaded, one will be a behaviour pack, the other will be a resource pack. Let's import both to the client by simply double clicking them.
- After that, let's create a new single player world and under 'Add-Ons', select both.
- Once created, we can verify in creative that it does work in single player by simply searching for an amethyst ring: https://i.geri.dev/sQIRTPXwBGj5.png
Now, let's exit out of this world and copy the files into a server.
- Download the dedicated server files from https://www.minecraft.net/en-us/download/server/bedrock (Apparently only the Beta one is available there currently so we'll use the latest stable instead, `v1.18.31`)
- Upload the freshly created world folder from `%LocalAppData%\Packages\Microsoft.MinecraftUWP_8wekyb3d8bbwe\LocalState\games\com.mojang\minecraftWorlds` to `./worlds/` on the server and rename it to `Bedrock level`.
- Start the server directly and attempt to connect.
On a working machine, here is what we'll see:
- Login screen: Shows that we would have to download 0.04 MB to apply the resource pack (see below about the cache) — https://i.geri.dev/vI1nYpMRyzHk.png
- Once logged in, we can search for the amethyst ring without any issues: https://i.geri.dev/2YpxTzICd7fP.png
On a machine that has `XFS` with `ftype=0`, here is what we see:
- Login screen: Shows that we'd only need to download 0.02 MB (see about cache below) — https://i.geri.dev/maxb4yn9SdoA.png
- In game, we cannot view any new items such as the amethyst ring — https://i.geri.dev/pPaLxrJnyHCi.png
—
Additionally, this happens to all players on different devices from further testing.
As for the cache, it looks like if you already connected to a world with the exact resource / behaviour packs, it will store it locally so the download screen may not match correctly. As such, we made sure to clear the game's cache through Main Menu ➜ 'Settings' ➜ 'Storage' when possible just so that is not the problem.
We have also tried numerous times to manually install these behaviour packs just in case single player did it incorrectly — though it seems to be doing it perfectly as the `world_resource_packs.json` and `world_behavior_packs.json` seems to always match the data in the packs' `manifest.json` information.
For convenience, we have compiled a ZIP archive of an entire server that has issues when running on a machine with the conditions mentioned above: https://archive.geri.dev/bedrock_test.zip (~73 MB total)
![[Bot] Arisa](../../../data/avatars/users/43007.png){kind=small}
Issue
Behaviour/resource packs are not loaded when run on a Linux machine with `XFS` as the filesystem and the `ftype` flag set to `0`.
We discovered an issue recently where a number of our Linux machines had Bedrock Dedicated Servers which would not load behaviour/resource packs. After some investigation we found the only real difference between machines that did work and machines that didn't were the file system:
- CentOS 7 `ext4`: works
- CentOS 7 `XFS`: works
- Almalinux 8 `ext4`: works
- Almalinux 8 `XFS` with `ftype=1`: works
- Almalinux 8 `XFS` with `ftype=0`: does not work
The flag seems to be purely a metadata structure thing so we are unsure why this would cause an issue.
Unfortunately, changing the flag requires rebuilding the entire filesystem (aka, reinstalling the OS). — This isn't feasible for us so we hope there's a way this can be resolved upstream.
—Replication Process
- For demonstration purposes, let's use a known working one from a public library: https://mcpedl.com/extended-amethyst-add-on/ (though any would work as far as we can tell)
- Once the files are downloaded, one will be a behaviour pack, the other will be a resource pack. Let's import both to the client by simply double
clicking them.
- After that, let's create a new single player world and under 'Add-Ons', select both.
- Once created, we can verify in creative that it does work in single
player by simply searching for an amethyst ring: https://i.geri.dev/sQIRTPXwBGj5.png
Now, let's exit out of this world and copy the files into a server.
- Download the dedicated server files from https://www.minecraft.net/en-us/download/server/bedrock (Apparently only the Beta one is available there currently so we'll use the latest stable instead, `v1.18.31`)
- Upload the freshly created world folder from `%LocalAppData%\Packages\Microsoft.MinecraftUWP_8wekyb3d8bbwe\LocalState\games\com.mojang\minecraftWorlds` to `./worlds/` on the server and rename it to `Bedrock level`.
- Start the server directly and attempt to connect.
On a working machine, here is what we'll see:
- Login screen: Shows that we would have to download 0.04 MB to apply the resource pack (see below about the cache) —
https://i.geri.dev/vI1nYpMRyzHk.png- Once logged in, we can search for the amethyst ring without any issues: https://i.geri.dev/2YpxTzICd7fP.png
On a machine that has `XFS` with `ftype=0`, here is what we see:
- Login screen: Shows that we'd only need to download 0.02 MB (see about cache below) —
https://i.geri.dev/maxb4yn9SdoA.png- In
game, we cannot view any new items such as the amethyst ring — https://i.geri.dev/pPaLxrJnyHCi.png—
Additionally, this happens to all players on different devices from further testing.
As for the cache, it looks like if you already connected to a world with the exact resource
/behaviour packs, it will store it locally so the download screen may not match correctly. As such, we made sure to clear the game's cache through Main Menu ➜ 'Settings' ➜ 'Storage' when possible just so that is not the problem.We have also tried numerous times to manually install these behaviour packs just in case single player did it incorrectly — though it seems to be doing it perfectly as the `world_resource_packs.json` and `world_behavior_packs.json` seems to always match the data in the packs' `manifest.json` information.
For convenience, we have compiled a ZIP archive of an entire server that has issues when running on a machine with the conditions mentioned above: https://archive.geri.dev/bedrock_test.zip (~73 MB total)
Issue
Behaviour/resource packs are not loaded when run on a Linux machine with `XFS` as the filesystem and the `ftype` flag set to `0`.
We discovered an issue recently where a number of our Linux machines had Bedrock Dedicated Servers which would not load behaviour/resource packs. After some investigation we found the only real difference between machines that did work and machines that didn't were the file system:
- CentOS 7 `ext4`: works
- CentOS 7 `XFS`: works
- Almalinux 8 `ext4`: works
- Almalinux 8 `XFS` with `ftype=1`: works
- Almalinux 8 `XFS` with `ftype=0`: does not work
The flag seems to be purely a metadata structure thing so we are unsure why this would cause an issue.
Unfortunately, changing the flag requires rebuilding the entire filesystem (aka, reinstalling the OS). — This isn't feasible for us so we hope there's a way this can be resolved upstream.
Replication Process
- For demonstration purposes, let's use a known working one from a public library: https://mcpedl.com/extended-amethyst-add-on/ (though any would work as far as we can tell)
- Once the files are downloaded, one will be a behaviour pack, and the other will be a resource pack. Let's import both to the client by simply double-clicking them.
After that, let's create a new single-player world and under 'Add-Ons', select both.
- Once created, we can verify in creative that it does work in single-player by simply searching for an amethyst ring: https://i.geri.dev/sQIRTPXwBGj5.png
- Now, let's exit out of this world and copy the files into a server.
- Download the dedicated server files from https://www.minecraft.net/en-us/download/server/bedrock (Apparently only the Beta one is available there currently so we'll use the latest stable instead, `v1.18.31`)
- Upload the freshly created world folder from `%LocalAppData%\Packages\Microsoft.MinecraftUWP_8wekyb3d8bbwe\LocalState\games\com.mojang\minecraftWorlds` to `./worlds/` on the server and rename it to `Bedrock level`.
- Start the server directly and attempt to connect.
On a working machine, here is what we'll see:
- Login screen: Shows that we would have to download 0.04 MB to apply the resource pack (see below about the cache) — https://i.geri.dev/vI1nYpMRyzHk.png
- Once logged in, we can search for the amethyst ring without any issues: https://i.geri.dev/2YpxTzICd7fP.png
On a machine that has `XFS` with `ftype=0`, here is what we see:
- Login screen: Shows that we'd only need to download 0.02 MB (see about cache below) — https://i.geri.dev/maxb4yn9SdoA.png
- In-game, we cannot view any new items such as the amethyst ring — https://i.geri.dev/pPaLxrJnyHCi.png
More Information
Additionally, this happens to all players on different devices from further testing.
As for the cache, it looks like if you already connected previously to a world with the exact resource/behaviour packs, it will store it locally so the download screen may not match correctly. As such, we made sure to clear the game's cache through Main Menu ➜ 'Settings' ➜ 'Storage' when possible just so that is not the problem.
We have also tried numerous times to manually install these behaviour packs just in case single player did it incorrectly — though it seems to be doing it perfectly as the `world_resource_packs.json` and `world_behavior_packs.json` seems to always match the data in the packs' `manifest.json` information.
For convenience, we have compiled a ZIP archive of an entire server that has issues when running on a machine with the conditions mentioned above: https://archive.geri.dev/bedrock_test.zip (~73 MB total)
Issue
Behaviour/resource packs are not loaded when run on a Linux machine with `XFS` as the filesystem and the `ftype` flag set to `0`.
We discovered an issue recently where a number of our Linux machines had Bedrock Dedicated Servers which would not load behaviour/resource packs. After some investigation we found the only real difference between machines that did work and machines that didn't were the file system:
- CentOS 7 `ext4`: works
- CentOS 7 `XFS`: works
- Almalinux 8 `ext4`: works
- Almalinux 8 `XFS` with `ftype=1`: works
- Almalinux 8 `XFS` with `ftype=0`: does not work
The flag seems to be purely a metadata structure thing so we are unsure why this would cause an issue.
Unfortunately, changing the flag requires rebuilding the entire filesystem (aka, reinstalling the OS). — This isn't feasible for us so we hope there's a way this can be resolved upstream.
Replication Process
- For demonstration purposes, let's use a known working one from a public library: https://mcpedl.com/extended-amethyst-add-on/ (though any would work as far as we can tell)
- Once the files are downloaded, one will be a behaviour pack, and the other will be a resource pack. Let's import both to the client by simply double-clicking them.
After that, let's create a new single-player world and under 'Add-Ons', select both.
- Once created, we can verify in creative that it does work in single-player by simply searching for an amethyst ring: https://i.geri.dev/sQIRTPXwBGj5.png
- Now, let's exit out of this world and copy the files into a server.
- Download the dedicated server files from https://www.minecraft.net/en-us/download/server/bedrock (Apparently only the Beta one is available there currently so we'll use the latest stable instead, `v1.18.31`)
- Upload the freshly created world folder from `%LocalAppData%\Packages\Microsoft.MinecraftUWP_8wekyb3d8bbwe\LocalState\games\com.mojang\minecraftWorlds` to `./worlds/` on the server and rename it to `Bedrock level`.
- Start the server directly and attempt to connect.
On a working machine, here is what we'll see:
- Login screen: Shows that we would have to download 0.04 MB to apply the resource pack (see below about the cache) — https://i.geri.dev/vI1nYpMRyzHk.png
- Once logged in, we can search for the amethyst ring without any issues: https://i.geri.dev/2YpxTzICd7fP.png
On a machine that has `XFS` with `ftype=0`, here is what we see:
- Login screen: Shows that we'd only need to download 0.02 MB (see about cache below) — https://i.geri.dev/maxb4yn9SdoA.png
- In-game, we cannot view any new items such as the amethyst ring — https://i.geri.dev/pPaLxrJnyHCi.png
More Information
Additionally, this happens to all players on different devices from further testing.
As for the cache, it looks like if you already connected previously to a world with the exact resource/behaviour packs, it will store it locally so the download screen may not match correctly. As such, we made sure to clear the game's cache through Main Menu ➜ 'Settings' ➜ 'Storage' when possible just so that is not the problem.
We have also tried numerous times to manually install these behaviour packs just in case single player did it incorrectly — though it seems to be doing it perfectly as the `world_resource_packs.json` and `world_behavior_packs.json` seems to always match the data in the packs' `manifest.json` information.
For convenience, we have compiled a ZIP archive of an entire server that has issues when running on a machine with the conditions mentioned above: https://archive.geri.dev/bedrock_test.zip (~73 MB total)
Issue
Behaviour/resource packs are not loaded when run on a Linux machine with `XFS` as the filesystem and the `ftype` flag set to `0`.
We discovered an issue recently where a number of our Linux machines had Bedrock Dedicated Servers which would not load behaviour/resource packs. After some investigation we found the only real difference between machines that did work and machines that didn't were the file system:
- CentOS 7 `ext4`: works
- CentOS 7 `XFS`: works
- Almalinux 8 `ext4`: works
- Almalinux 8 `XFS` with `ftype=1`: works
- Almalinux 8 `XFS` with `ftype=0`: does not work
The flag seems to be purely a metadata structure thing so we are unsure why this would cause an issue.
Unfortunately, changing the flag requires rebuilding the entire filesystem (aka, reinstalling the OS). — This isn't feasible for us so we hope there's a way this can be resolved upstream.
Replication Process
1. For demonstration purposes, let's use a known working one from a public library: https://mcpedl.com/extended-amethyst-add-on/ (though any would work as far as we can tell)
2. Once the files are downloaded, one will be a behaviour pack, and the other will be a resource pack. Let's import both to the client by simply double-clicking them.
3. After that, let's create a new single-player world and under 'Add-Ons', select both.
4. Once created, we can verify in creative that it does work in single-player by simply searching for an amethyst ring: https://i.geri.dev/sQIRTPXwBGj5.png
Now, let's exit out of this world and copy the files into a server.5. Download the dedicated server files from https://www.minecraft.net/en-us/download/server/bedrock (Apparently only the Beta one is available there currently so we'll use the latest stable instead, `v1.18.31`)
6. Upload the freshly created world folder from `%LocalAppData%\Packages\Microsoft.MinecraftUWP_8wekyb3d8bbwe\LocalState\games\com.mojang\minecraftWorlds` to `./worlds/` on the server and rename it to `Bedrock level`.
7. Start the server directly and attempt to connect.
On a working machine, here is what we'll see:
- Login screen: Shows that we would have to download 0.04 MB to apply the resource pack (see below about the cache) — https://i.geri.dev/vI1nYpMRyzHk.png
- Once logged in, we can search for the amethyst ring without any issues: https://i.geri.dev/2YpxTzICd7fP.png
On a machine that has `XFS` with `ftype=0`, here is what we see:
- Login screen: Shows that we'd only need to download 0.02 MB (see about cache below) — https://i.geri.dev/maxb4yn9SdoA.png
- In-game, we cannot view any new items such as the amethyst ring — https://i.geri.dev/pPaLxrJnyHCi.png
More Information
Additionally, this happens to all players on different devices from further testing.
As for the cache, it looks like if you already connected previously to a world with the exact resource/behaviour packs, it will store it locally so the download screen may not match correctly. As such, we made sure to clear the game's cache through Main Menu ➜ 'Settings' ➜ 'Storage' when possible just so that is not the problem.
We have also tried numerous times to manually install these behaviour packs just in case single player did it incorrectly — though it seems to be doing it perfectly as the `world_resource_packs.json` and `world_behavior_packs.json` seems to always match the data in the packs' `manifest.json` information.
For convenience, we have compiled a ZIP archive of an entire server that has issues when running on a machine with the conditions mentioned above: https://archive.geri.dev/bedrock_test.zip (~73 MB total)
![[Mod] OcelotOnesie](../../../data/avatars/users/43220.png){kind=small}
MCPE-156545 → 
BDS-17043![[Mod] Jarl-Penguin](../../../data/avatars/users/92849.png){kind=small}
– I am a bot. This action was performed automatically! If you think it was incorrect, please notify us on Discord or Reddit
Shortly after posting it, I realized there was a dedicated section for BDS. — I'm unsure whether moving it to that section would be more appropriate but apologies for the headache.
The issue appears to be present on the latest release of The Wild Update. The client says it's using v1.19.0 while BDS itself is using v1.19.1.01 if I understand correctly.
Using the same setup, it works perfectly unless it is on AlmaLinux with XFS using ftype=0.
The 1.19 files can be downloaded from here: https://archive.geri.dev/bedrock_test_v2.zip
This still appears to be an issue in the latest BDS version (v1.19.2.xx) downloaded from https://minecraft.azureedge.net/bin-linux/bedrock-server-1.19.2.02.zip
I don't think mojang accept issues for linux distros other then ubuntu and I think another distro
Thank you for your report!
However, this issue is Invalid.
Only Ubuntu 18 and later versions are supported.
Quick Links:
📓 Bug Tracker Guidelines – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 BDS Wiki – 📖 FAQs
I can confirm the issue presents itself on Ubuntu 22.04
Also had a hunch that it could have been due to the filesystems CRC setting but this does not seem to be the case. It seems to only fail if ftype=0 is specified when generating the XFS filesystem.
Hi
Does this issue still occur after updating to 1.19.22?
This ticket will automatically reopen when you reply.
This is still indeed an issue, though it seems like I was able to discover some more information.
On systems using XFS with the `ftype` flag set to `0` servers with these resource packs were no longer able to launch.
Here is a download link to the testing files: https://archive.geri.dev/bedrock_test_v3.zip
For reference, here is what happens on all of our other nodes that are working, where we use different file system types or `ftype` `1`:
—
On a node with XFS and `ftype` 0, here is the startup crash: https://p.geri.dev/raw/lewipejokeficagoqifo
Out of curiosity, I tried disabling the resource/behaviour pack to see if that's the issue and it still crashed with the same log.
After poking around I found that simply removing the `level.dat` file allows the server to launch even when the resource/behaviour packs are enabled.
I do not know much about the format of this file but from reading the wiki, it seems like experiments are stored here: https://minecraft.fandom.com/wiki/Bedrock_Edition_level_format#level.dat
After a closer look and a DIFF check, it does seem like the freshly generated `level.dat` file has none of the experiments: https://i.geri.dev/iuKaQpolLV7j.png (aside from some of the other, seemingly irrelevant differences)
Just to confirm, I checked in-game and indeed the resource/behaviour packs are not working without these experiments: https://i.geri.dev/9dGTxw3Dy0Om.png
I went back to check if these specific experiments were enabled for the packs that we reported before and that indeed appears to have been the case.
Using a combination of hex editors and other 3rd party tools, I was able to modify the original level.dat to discover that in this case, the `gametest` experiment when it's set to `1` was causing this crash
Modifying the `level.dat` file to set this to `0` allowed the server to boot without crashes and the resource/behaviour packs worked without any issues as well.
For reference, here are all the files at the end of this test: https://archive.geri.dev/bedrock_test_v4.zip
—
Lastly, I tested a resource as well as a behaviour pack that did not require any experiments to be enabled and sure enough, that appears to work without any issues as well across all different file system types and file system flags.
—
To summarize: It seems like the issue is being caused by some of these experiments that are failing to load correctly on systems using the XFS file system type with the `ftype` flag set to `1`.
While we completely understand that experiments are just that and may cause instability, it'd be great if the team could check why it would not work on such a widely used file system type and configuration.
Though with the mentioned configuration and full server file downloads, it should be fairly easy to replicate this issue, we would be more than happy to provide a testing server and tools to replicate this issue consistently.
Thanks,
Geri K.
Unable to run scripts under an `xfs` filesystem if the `ftype` is set to 0. This issue continues to be a problem and identical to the issue we were having a year ago.
I’ve entirely isolated this issue to a VPS using the service called `Vulr` and replicated the problem by doing the following. This is worth noting as when installing `AlmaLinux` as the (“Host Machine”) with an xfs filesystem it was `ext4` in this environment.
Additional things to note. We do know this isn’t meant to be run on AlmaLinux, and we run our bedrock servers in docker running Ubuntu. However, since the (“Host Machine”) is an xfs filesystem with ftype=0. This will cause (“scripts”) to fail. We isolated it to make sure it wasn’t a docker-related issue, and it’s not.
If you use `Vultr` they do have a scripts area where you can easily copy/paste to build this server from scratch and don’t have to manually do it. The main command is creating partitions with the `mkfs.xfs` parameters.
Once the server has booted or completed the tasks.
If everything looks set up properly. We’re going to build a server mostly from scratch. This will create the essential files/worlds required.
The next step is the scripts. You can find your own scripts or use the one provided. This includes behavior and resource packs and a modified `level.dat` to enable experimental builds. Might want to do this manually to ensure the files get extracted properly.
Next, we will proceed by copying these same files into the new directories/partitions we created earlier.
Modify the ports to avoid conflicts or just run one at a time.
Let us confirm the issue. Go into each directory and start the server respectively.
You will see that `ext4` and `ftype1` works perfectly fine, and for `ftype0` the scripts don’t load at all. Keep in mind these are identical servers we just copied and the 2 main differences are the filesystem and server port.
This is where it becomes interesting…
This will load the scripts fine. However, if we switch to:
cd /ftype0/ screen -dmS bedrock_ext4 /home/new/bedrock_server; screen -x bedrock_ext4Do you notice we’re using the same `screen` command as above? The difference in this case, we ran the command from `/ftype0` and the result is that it failed. However, we run it from `cd /home/new/` directly. It doesn’t fail. Not likely a path issue per Se. This is still a `ftype=0` issue and needs to be resolved.