[Bug]: Local external storage is listed by DAV but child directories return 404

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

I am using a Local external storage mounted inside the Nextcloud Docker container as:

/mnt/nas-photo

The storage is configured in Nextcloud Files External as:

/Fotky_local -> Local (server storage) -> /mnt/nas-photo

The mount itself is accessible from the Nextcloud container and Nextcloud's internal filesystem API can resolve and list its directories.

However, navigation through the Files UI is unreliable. The top-level directories initially appear, but opening them may result in an empty directory or the directory disappearing from the listing.

The same behavior is reproducible directly through Nextcloud DAV.

A PROPFIND with Depth: 1 on:

/remote.php/dav/files/hacesoft/Fotky_local/

returns HTTP 207 and correctly lists child directories including:

Fotky_local/Tata/
Fotky_local/Mama/
Fotky_local/Zuza/

However, immediately requesting one of those returned paths directly, for example:

/remote.php/dav/files/hacesoft/Fotky_local/Tata/

returns HTTP 404:

Sabre\DAV\Exception\NotFound
File with name /Fotky_local/Tata could not be located

At the same time, Nextcloud's internal filesystem API resolves exactly the same directory successfully and reports it as readable.

Steps to reproduce

1. Bind-mount a host directory containing existing files/directories into the Nextcloud Docker container, for example as /mnt/nas-photo.

2. Configure it in Nextcloud Administration settings -> External storage as:

   • Storage: Local
   • Mount point: /Fotky_local
   • Path: /mnt/nas-photo

3. Run:
   php occ files:scan --path="hacesoft/files/Fotky_local"

4. Open Files -> Fotky_local. The top-level directories are initially visible.

5. Try to open a child directory such as Tata, Mama or Zuza. The directory may appear empty, disappear from the listing, or fail to open.

6. Perform a DAV PROPFIND Depth: 1 on:
   /remote.php/dav/files/hacesoft/Fotky_local/

   It returns HTTP 207 and lists, among others:
   /Fotky_local/Tata/
   /Fotky_local/Mama/
   /Fotky_local/Zuza/

7. Perform a DAV PROPFIND directly on one of the paths returned in step 6:
   /remote.php/dav/files/hacesoft/Fotky_local/Tata/

   It returns HTTP 404 with:
   Sabre\DAV\Exception\NotFound
   File with name /Fotky_local/Tata could not be located

Expected behavior

A child directory returned by a successful DAV PROPFIND of the parent directory should also be directly accessible through DAV.

For example, if:

PROPFIND /Fotky_local/

returns:

/Fotky_local/Tata/

then:

PROPFIND /Fotky_local/Tata/

should return HTTP 207 and list the contents of that directory.

The same directories should remain visible and navigable in the Nextcloud Files UI.

Nextcloud Server version

34

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.5

Web server

Apache (supported)

Database engine version

MariaDB

Is this bug present after an update or on a fresh install?

None

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

sudo docker exec -u www-data nextcloud-app php occ config:list system
{
    "system": {
        "auth.session.enforce": false,
        "auth.session.lifetime": 86400,
        "htaccess.RewriteBase": "\/",
        "memcache.local": "\\OC\\Memcache\\APCu",
        "apps_paths": [
            {
                "path": "\/var\/www\/html\/apps",
                "url": "\/apps",
                "writable": false
            },
            {
                "path": "\/var\/www\/html\/custom_apps",
                "url": "\/custom_apps",
                "writable": true
            }
        ],
        "memcache.distributed": "\\OC\\Memcache\\Redis",
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "password": "***REMOVED SENSITIVE VALUE***",
            "port": 6379
        },
        "upgrade.disable-web": true,
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "allow_local_remote_servers": true,
        "onlyoffice": {
            "verify_peer_off": true
        },
        "trusted_domains": [
            "linea917.myds.me:9481"
        ],
        "trusted_proxies": "***REMOVED SENSITIVE VALUE***",
        "overwriteprotocol": "https",
        "overwritehost": "linea917.myds.me:9481",
        "overwrite.cli.url": "https:\/\/linea917.myds.me:9481",
        "overwritewebroot": "\/",
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "34.0.3.2",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "maintenance": false,
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpmode": "smtp",
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "9125",
        "mail_sendmailmode": "smtp",
        "mail_smtpstreamoptions": {
            "ssl": {
                "allow_self_signed": true,
                "verify_peer": false,
                "verify_peer_name": false
            }
        },
        "config_preset": 2,
        "defaultapp": "dashboard,files,photos,activity,mail,contacts,calendar,office",
        "maintenance_window_start": 1,
        "default_phone_region": "CZ",
        "enable_previews": true,
        "preview_max_x": 2048,
        "preview_max_y": 2048,
        "app_install_overwrite": [],
        "loglevel": 2,
        "log_rotate_size": 104857600,
        "log_max_history": 5,
        "memories.db.triggers.fcu": true,
        "memories.exiftool": "\/var\/www\/html\/custom_apps\/memories\/bin-ext\/exiftool-amd64-glibc",
        "memories.vod.path": "\/var\/www\/html\/custom_apps\/memories\/bin-ext\/go-vod-amd64",
        "enabledPreviewProviders": [
            "OC\\Preview\\JPEG",
            "OC\\Preview\\PNG",
            "OC\\Preview\\GIF",
            "OC\\Preview\\BMP",
            "OC\\Preview\\HEIC",
            "OC\\Preview\\TIFF",
            "OC\\Preview\\Movie"
        ],
        "memories.gis_type": 1,
        "memories.vod.disable": false,
        "memories.vod.ffprobe": "\/usr\/bin\/ffprobe",
        "memories.vod.ffmpeg": "\/usr\/bin\/ffmpeg",
        "davstorage.request_timeout": 300,
        "preview_max_memory": 512
    }
}

List of activated Apps

php occ integrity:check-core 
Could not open input file: occ

 php occ integrity:check-app maps
Could not open input file: occ

Nextcloud Signing status

Nextcloud Logs

Additional info

Exact Nextcloud version: Nextcloud Hub 26 Spring (34.0.3)
Installation: Docker Compose on Synology NAS
Container OS: Debian GNU/Linux 13.6 (trixie)
PHP: 8.5.9
Web server: Apache 2.4.68 (mpm_prefork + mod_php)
Database: MariaDB 10.6.27

The filesystem itself appears to be accessible correctly from the Nextcloud container.

Direct access from the container shows the directories and their contents.

Nextcloud's internal filesystem API also resolves the affected paths successfully:

Fotky_local : OK id=168236 type=dir readable=YES
Fotky_local/Tata : OK id=303060 type=dir readable=YES
Fotky_local/Tata/DCIM : OK id=303068 type=dir readable=YES
Fotky_local/Mama : OK id=325716 type=dir readable=YES
Fotky_local/Zuza : OK id=327973 type=dir readable=YES

Directory listing through the internal API also works, for example:

PATH: /hacesoft/files/Fotky_local/Tata
ID: 303060
COUNT: 1
TIME: 0.001 s
DCIM

A complete scan of the external storage also completed without errors:

Folders: 12207
Files: 97754
New: 0
Updated: 83
Removed: 0
Errors: 0
Elapsed time: 00:01:02

The mount is reported by Nextcloud as:

/hacesoft/files/Fotky_local/: local::/mnt/nas-photo/
provider: OCA\Files_External\Config\ConfigAdapter
storage id: 15
root id: 168236

Therefore the underlying filesystem, Local external-storage backend and Nextcloud filesystem API appear able to access the directories. The inconsistent behavior appears when resolving the child path through DAV.

Why I am switching from WebDAV to Local storage

The same photo/video library was previously exposed to Nextcloud through WebDAV.

File browsing through WebDAV works, but video playback frequently stutters or buffers on mobile devices, while the same videos play normally on desktop devices.

The library is mainly used with Nextcloud Memories.

Because the original files are physically stored on the same NAS that runs the Nextcloud Docker containers, I am trying to avoid the unnecessary WebDAV layer and expose the filesystem directly:

Current/previous:
Nextcloud -> WebDAV -> NAS filesystem

Desired:
Nextcloud -> Local external storage (/mnt/nas-photo) -> NAS filesystem

I have not established that transcoding itself is the cause of the mobile playback issue, but direct Local access is desirable both to eliminate the additional WebDAV layer and to investigate/improve this playback behavior.

The photo/video library contains approximately 98,000 files.

Reproduce the failure with php occ files:scan --path="hacesoft/files/Fotky_local", then compare the DAV PROPFIND requests for /Fotky_local/ and /Fotky_local/Tata/ with the internal filesystem API results described here. Trace the DAV path-resolution entry point for local external storage; done means child directories listed by the parent are directly accessible through DAV and remain navigable in Files.