Error Creating Directory

Support
1

2025-10-27 09:49:42: Failed to create folder root directory (folder.label=“Test it” folder.id=drbhr-auiwu folder.type=sendreceive error=“mkdir /home/markr: permission denied” log.pkg=model)

2025-10-27 09:49:42: Failed initial scan (error=“folder path missing” folder.label=“Test it” folder.id=drbhr-auiwu folder.type=sendreceive log.pkg=model)

Linux system running current version of Cinnamon . I receive this message when I try and create a shared folder. It reports the same error no matter which computer the share is originated. I opened up permissions completely and still receive the error. I have other instances running on a laptop that work fine. I have spent a day and a half working with it and don’t know where to turn. Any ideas would be welcomed.

Syncthing Troubleshooting Log - Moon System

Date: October 26, 2025 System: Linux Mint (Moon laptop) Issue: Failed to create folder root directory - “mkdir /home/markr: permission denied”

Problem Description

Syncthing consistently fails to sync folders with error:

Failed to create folder root directory (error="mkdir /home/markr: permission denied")
Failed initial scan (error="folder path missing")

Key Observation: Same configuration works perfectly on MooToo laptop, but fails on Moon.

Initial Investigation

1. Error Analysis

  • Error shows Syncthing attempting to create /home/markr instead of the configured subdirectory
  • Multiple folder IDs tested: yjup3-9gtde, 6mwvn-myofx, 9pvyr-sytv7, iztaj-rrniy, keyp6-wusra, dapy6-ovoo7, hjsxj-envqs, mo274-d2cc6
  • Error persisted regardless of folder ID or configuration

2. Configuration Verification

  • Config XML always showed correct paths (e.g., /home/markr/Documents, /home/markr/Sync)
  • API queries confirmed correct path configuration
  • Web UI displayed correct paths

Troubleshooting Steps Attempted

1. Path Configuration Changes

Paths Tested:

  • /home/markr/Documents - Failed
  • /home/markr/SyncDocuments - Failed
  • /home/markr/Sync - Failed
  • /home/markr/Documents/Sync - Failed
  • /tmp/synctest - (Not fully tested)

Actions:

  • Changed folder paths via config file edits
  • Changed paths via API PATCH requests
  • Changed paths via web UI

Result: All subdirectory paths under /home/markr triggered the same error

2. Syncthing Database Cleanup

Databases Removed:

rm -rf ~/syncthing/index-v0.14.0.db
rm -rf ~/syncthing/config/config/index-v2
rm -rf ~/.local/state/syncthing/index-v0.14.0.db

Result: Error persisted after database regeneration

3. Marker File Creation

Created .stfolder marker directories:

mkdir -p /home/markr/Documents/.stfolder
mkdir -p /home/markr/Documents/Sync

Result: No effect on error

4. Syncthing Version Changes

Original Version: v1.27.2-ds4 (Debian package)

  • Suspected as buggy Debian-specific build
  • Removed Debian package

Upgrade to Official Release:

sudo apt remove syncthing
sudo curl -L -o /etc/apt/keyrings/syncthing-archive-keyring.gpg https://syncthing.net/release-key.gpg
echo "deb [signed-by=/etc/apt/keyrings/syncthing-archive-keyring.gpg] https://apt.syncthing.net/ syncthing stable" | sudo tee /etc/apt/sources.list.d/syncthing.list
sudo apt update
sudo apt install syncthing

New Version: v1.30.0 (official)

Result: Same error persisted with official release

5. AppArmor Investigation

Discovery: Syncthing was running under docker-default AppArmor profile

sudo aa-status | grep syncthing
# Output: /usr/bin/syncthing (PID) docker-default

Attempted Fixes:

  1. Created systemd override to disable AppArmor:
mkdir -p ~/.config/systemd/user/syncthing.service.d/
cat > ~/.config/systemd/user/syncthing.service.d/override.conf << EOF
[Service]
AppArmorProfile=
EOF
  1. Reloaded systemd and restarted:
systemctl --user daemon-reload
systemctl --user restart syncthing

Verification:

cat /proc/$(pgrep -f "syncthing serve")/attr/current
# Output: unconfined

Result: AppArmor was successfully removed, but error persisted

6. Permissions Testing

Original Permissions:

ls -ld /home/markr
# drwxr-x--- (750)

Permission Change Test:

sudo chmod 755 /home/markr

Result: Error still occurred even with open permissions

Restored Original:

sudo chmod 750 /home/markr

7. Symlink Workaround Attempt

mv /home/markr/Documents /home/markr/Documents_real
ln -s Documents_real /home/markr/Documents

Result: No effect on error

Reverted:

rm /home/markr/Documents
mv /home/markr/Documents_real /home/markr/Documents

8. Complete Reinstallation

Steps:

  1. Stopped Syncthing service
  2. Removed all Syncthing data:
rm -rf ~/syncthing
rm -rf ~/.config/syncthing
rm -rf ~/.local/share/syncthing
rm -rf ~/.local/state/syncthing
  1. Reinstalled Syncthing package:
sudo apt reinstall syncthing
  1. Started fresh with new configuration

Result: Error persisted even with completely fresh installation

9. Binary Path Issues

Problem Discovered: /bin/syncthing phantom binary

  • Process showed /bin/syncthing instead of /usr/bin/syncthing
  • Binary didn’t actually exist at that path

Resolution:

sudo apt reinstall syncthing

Result: Correct binary path restored, but error persisted

System Information

Permissions Verification

ls -ldn /home/markr
# drwxr-x--- 24 1000 1000 4096 Oct 26 07:54 /home/markr

id
# uid=1000(markr) gid=1000(markr) groups=1000(markr),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),100(users),105(lpadmin),125(sambashare),127(docker)

Filesystem Information

stat -f /home/markr
# Type: ext2/ext3 (ext4)
# Block size: 4096

Syncthing Process Information

ps -o user,uid,gid,cmd -p $(pgrep syncthing)
# USER: markr
# UID: 1000
# GID: 1000
# CMD: /usr/bin/syncthing serve --no-browser --no-restart

Configuration Files Examined

Config Locations

  • /home/markr/syncthing/config/config/config.xml
  • ~/.local/state/syncthing/config.xml

Sample Folder Configuration (from config.xml)

<folder id="keyp6-wusra" label="Linux Documents" path="/home/markr/Documents" type="sendreceive">
    <device id="H5JGHX2-TUE4CVB-DEAERO5-7OSJBRV-4G6FMLZ-UQPX4U2-JUKEPRO-FFDKXAO">
        <!-- NAS device -->
    </device>
</folder>

API Verification

curl -s -H "X-API-Key: gsn2kRK45mvyKLaehr4Stbg9d66b3xda" http://localhost:8384/rest/config/folders | python3 -m json.tool
# Confirmed path: "/home/markr/Documents"

Key Findings

  1. Configuration is Always Correct

    • Config files show proper subdirectory paths
    • API returns correct paths
    • Web UI displays correct paths

  2. Error Message is Misleading

    • Syncthing reports trying to create /home/markr
    • Should be creating subdirectory like /home/markr/Documents
    • Appears to be path parsing bug

  3. Works on MooToo, Fails on Moon

    • Identical configuration works on MooToo laptop
    • Same Syncthing version
    • Same folder structure
    • Same NAS as source

  4. Not Permission-Related

    • Error persists with 755 permissions
    • Syncthing runs as correct user (markr, uid 1000)
    • Owner matches directory owner

  5. Not AppArmor-Related

    • Removed AppArmor restrictions
    • Verified process runs unconfined
    • Error still occurs

  6. Not Version-Related

    • Occurred with Debian package (v1.27.2-ds4)
    • Occurred with official release (v1.30.0)

  7. Not Database-Related

    • Cleared databases multiple times
    • Fresh databases show same issue

Attempted Workarounds That Failed

  1. Manual directory creation with .stfolder marker
  2. Symlink redirection
  3. Permission changes
  4. Different subdirectory names
  5. Nested vs single-level paths
  6. AppArmor profile removal
  7. Complete reinstallation
  8. Database deletion and regeneration
  9. API-based configuration changes

Working Configuration (MooToo)

  • System: Linux Mint
  • Syncthing Version: (Not specified, but same package source)
  • Folder Path: /home/markr/Documents
  • Status: Works perfectly with no errors

Theories for Root Cause

Theory 1: Syncthing Code Bug on Moon’s Environment

  • Specific to Moon’s kernel version, libraries, or system configuration
  • Path parsing fails for /home/markr/* specifically
  • Bug triggered by environment variable or system setting unique to Moon

Theory 2: Filesystem State Issue

  • Possible ext4 filesystem corruption or metadata issue
  • /home/markr directory has unusual extended attributes or ACLs
  • Inode or directory entry corruption

Theory 3: System Library Mismatch

  • Go runtime library issue specific to Moon
  • System call interception or modification
  • Security module interfering at kernel level

Recommended Next Steps

Option 1: Test Alternative Root Path

Try syncing to location outside /home/markr:

mkdir -p /tmp/sync-test

Configure folder with path /tmp/sync-test

Expected Outcomes:

  • If works: Issue is specific to /home/markr
  • If fails with “mkdir /tmp: permission denied”: Syncthing is fundamentally broken

Option 2: File Bug Report

Report to Syncthing developers with:

  • This troubleshooting log
  • System information (uname -a, lsb_release -a)
  • Syncthing logs (journalctl --user -u syncthing -n 1000)
  • strace output showing actual syscalls

Option 3: Use MooToo Instead

  • MooToo works perfectly with identical configuration
  • No workaround needed
  • Simpler solution

Option 4: Nuclear Option - OS Reinstall

If Syncthing is critical on Moon:

  • Backup data
  • Reinstall Linux Mint
  • Test Syncthing before restoring data

Commands for Further Debugging

Enable Syncthing Debug Logging

systemctl --user stop syncthing
STTRACE=all /usr/bin/syncthing serve --no-browser > /tmp/syncthing-debug.log 2>&1 &

Capture System Call Trace

strace -f -o /tmp/syncthing-strace.log /usr/bin/syncthing serve --no-browser

Check for Filesystem Issues

sudo dmesg | grep -i error
sudo fsck -n /dev/sdX  # Replace with actual device

Verify Extended Attributes

getfattr -d -m '.*' /home/markr
lsattr /home/markr

Timeline of Events

  1. Initial Error Discovery - Syncthing fails with “mkdir /home/markr: permission denied”
  2. Path Changes - Tested multiple paths, all failed
  3. Database Cleanup - Deleted and regenerated databases
  4. Version Upgrade - Switched from Debian package to official release
  5. AppArmor Discovery - Found docker-default profile restricting Syncthing
  6. AppArmor Removal - Disabled AppArmor for Syncthing
  7. Permission Testing - Changed /home/markr to 755, then reverted
  8. Complete Reinstall - Removed all Syncthing data and reinstalled
  9. Fresh Database - Started with completely clean database
  10. Error Persists - All attempts failed to resolve issue

Conclusion

After exhaustive troubleshooting, the issue remains unresolved. The error “mkdir /home/markr: permission denied” occurs despite:

  • Correct configuration
  • Proper permissions
  • No AppArmor restrictions
  • Multiple fresh installations
  • Different paths and versions

The bug appears to be:

  • Environment-specific to Moon laptop
  • Related to path parsing in Syncthing code
  • Not reproducible on MooToo with identical config

Recommendation: Use MooToo for syncing, or report bug to Syncthing developers with full system diagnostics.

Contact Information

  • User: markr
  • System: Moon (Linux Mint)
  • Syncthing Version: v1.30.0
  • Issue Date: October 26, 2025
2

Seriously? How many people waste 4 minutes to read through all that AI generated crap of a failure description / analysis? Please tell us what’s wrong, concisely. Then we can gladly help.

2 Likes
3

Sorry. I thought it might help.

Conclusion

After exhaustive troubleshooting, the issue remains unresolved. The error “mkdir /home/markr: permission denied” occurs despite:

  • Correct configuration

  • Proper permissions

  • No AppArmor restrictions

  • Multiple fresh installations

  • Different paths and versions

4

What does “proper permissions” mean?

Have you checked which user owns the running syncthing process? How are you starting it, possibly including some access restrictions / security jail / container? Depending on how you start it, the security context may be different from when you type some “mkdir” commands into your terminal.

What platform / OS is this on?

P.S.: Sorry for the attitude about AI usage, but my experience with those chatbots shows that the answers are seemingly getting more erroneous and stupid day by day. Which perfectly mimics the development of human intellect, in general.

2 Likes
5

Thanks for making me think! I had Syncthings starting as a service giving root permissions. I need to test some more but I think it’s fixed. Stupid AI.

Thanks again!

Mark

6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.