[GH-ISSUE #561] Symlink doesn't show directories #332

Closed
opened 2026-04-08 16:52:06 +03:00 by zhus · 3 comments
Owner

Originally created by @danutzzzzz on GitHub (Mar 23, 2025).
Original GitHub issue: https://github.com/sigoden/dufs/issues/561

Problem

Hi, i have symlinked a couple of directories inside the root directory (/Share), but when viewing in dufs they do not appear.

Configuration

serve-path: './Share'
bind: 0.0.0.0
port: 5000
allow-all: false
allow-search: true
allow-symlink: true
enable-cors: true
render-index: true
render-try-index: true
render-spa: true
log-format: '$remote_addr "$request" $status $http_user_agent'
log-file: ./data/dufs.log
compress: low

Log

2025-03-23T01:28:26Z INFO - 10.0.30.10 "GET /" 200 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36 Edg/134.0.0.0
2025-03-23T01:28:26Z INFO - 10.0.30.10 "GET /__dufs_v0.43.0__/index.css" 200 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36 Edg/134.0.0.0
2025-03-23T01:28:26Z INFO - 10.0.30.10 "GET /__dufs_v0.43.0__/index.js" 200 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36 Edg/134.0.0.0
2025-03-23T01:28:26Z INFO - 10.0.30.10 "GET /__dufs_v0.43.0__/favicon.ico" 200 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36 Edg/134.0.0.0
2025-03-23T01:28:27Z INFO - 10.0.30.10 "GET /" 200 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36 Edg/134.0.0.0

Screenshots/Media

Environment Information

  • Dufs version: v0.43.0
  • Browser/Webdav info: EDGE / Windows 11 Pro
  • OS info: Debian/Docker
  • Proxy server (if any): N/A
Originally created by @danutzzzzz on GitHub (Mar 23, 2025). Original GitHub issue: https://github.com/sigoden/dufs/issues/561 **Problem** Hi, i have symlinked a couple of directories inside the root directory (/Share), but when viewing in dufs they do not appear. **Configuration** ``` serve-path: './Share' bind: 0.0.0.0 port: 5000 allow-all: false allow-search: true allow-symlink: true enable-cors: true render-index: true render-try-index: true render-spa: true log-format: '$remote_addr "$request" $status $http_user_agent' log-file: ./data/dufs.log compress: low ``` **Log** ``` 2025-03-23T01:28:26Z INFO - 10.0.30.10 "GET /" 200 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36 Edg/134.0.0.0 2025-03-23T01:28:26Z INFO - 10.0.30.10 "GET /__dufs_v0.43.0__/index.css" 200 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36 Edg/134.0.0.0 2025-03-23T01:28:26Z INFO - 10.0.30.10 "GET /__dufs_v0.43.0__/index.js" 200 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36 Edg/134.0.0.0 2025-03-23T01:28:26Z INFO - 10.0.30.10 "GET /__dufs_v0.43.0__/favicon.ico" 200 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36 Edg/134.0.0.0 2025-03-23T01:28:27Z INFO - 10.0.30.10 "GET /" 200 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36 Edg/134.0.0.0 ``` **Screenshots/Media** **Environment Information** - Dufs version: v0.43.0 - Browser/Webdav info: EDGE / Windows 11 Pro - OS info: Debian/Docker - Proxy server (if any): N/A
zhus closed this issue 2026-04-08 16:52:06 +03:00
Author
Owner

@sigoden commented on GitHub (Mar 24, 2025):

Windows .lnk (shortcut) files are not true symbolic links like those in Linux. They are more like references that tell Windows where to find a file or program but don’t function as actual filesystem-level links.

Windows does support actual symbolic links, but they work differently from .lnk files and require NTFS. You can create them using the mklink command:

  • Symbolic Link (Soft Link)
    mklink "C:\path\to\link" "C:\path\to\target"
    
  • Directory Junction (Alternative to Symlink for Directories)
    mklink /J "C:\path\to\link" "C:\path\to\target"
    

Unlike .lnk files, real symlinks and hard links work at the filesystem level, so applications and scripts treat them as if they are the actual files.

<!-- gh-comment-id:2746566572 --> @sigoden commented on GitHub (Mar 24, 2025): Windows `.lnk` (shortcut) files are not true symbolic links like those in Linux. They are more like references that tell Windows where to find a file or program but don’t function as actual filesystem-level links. ### **Real Symlinks in Windows** Windows does support actual symbolic links, but they work differently from `.lnk` files and require NTFS. You can create them using the **`mklink`** command: - **Symbolic Link (Soft Link)** ```cmd mklink "C:\path\to\link" "C:\path\to\target" ``` - **Directory Junction (Alternative to Symlink for Directories)** ```cmd mklink /J "C:\path\to\link" "C:\path\to\target" ``` Unlike `.lnk` files, real symlinks and hard links work at the filesystem level, so applications and scripts treat them as if they are the actual files.
Author
Owner

@danutzzzzz commented on GitHub (Mar 24, 2025):

@sigoden the symlink is in Linux using ln -s not windows

<!-- gh-comment-id:2746591723 --> @danutzzzzz commented on GitHub (Mar 24, 2025): @sigoden the symlink is in Linux using `ln -s` not windows
Author
Owner

@sigoden commented on GitHub (Mar 24, 2025):

This is probably a docker problem.

Docker cannot handle links that point to files outside of the Docker filesystem.

<!-- gh-comment-id:2746628375 --> @sigoden commented on GitHub (Mar 24, 2025): This is probably a docker problem. Docker cannot handle links that point to files outside of the Docker filesystem.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sigoden/dufs#332