'Loading ignores: permission denied' error on Linux (newbie)

Hi - I’ve tried my luck looking online for answers but unfortunately I don’t quite fully understand most of the troubleshooting, so I was hoping someone here could help me go through it.

I’m running a Pi as a server using SyncThing that connects to Windows machines but I’m coming across this error quite frequently:

Loading ignores: lstat /media/raspi4/NVME_usb/sync_folder1/.stignore: permission denied

From what I understand, this is due to SyncThing not having the necessary permissions to the folder where its located, so how can I fix it?

Below are the results of my ls -l if that helps:

ls -l /media/raspi4/NVME_usb/
total 32
drwxr-xr-x 5 raspi4 raspi4  4096 Apr 30 13:44 sync_folder1
drwxr-xr-x 3 raspi4 raspi4  4096 Apr 30 18:43 sync_folder2
drwxr-xr-x 7 raspi4 raspi4  4096 Apr 30 13:27 sync_folder3
drwxr-xr-x 4 raspi4 raspi4  4096 Apr 30 13:26 sync_folder4
drwx------ 2 root   root   16384 Apr 24 16:24 lost+found

Thanks for the help.

Is user raspi4 also the one running Syncthing?

How is Syncthing being launched?

Yes, it is. And it’s being launched via service on boot.

Which Linux distribution is the RPi running?

For the service start, are you using SystemD? If so, what was the command used? Was the SystemD unit file customized or are you using the stock file?

While logged in as user raspi4, what’s the output from the following command?

ls -lZ /media/raspi4/NVME_usb/sync_folder1/.stignore

Which Linux distribution is the RPi running?

I’m using PRETTY_NAME="Debian GNU/Linux 11 (bullseye)".

For the service start, are you using SystemD? If so, what was the command used? Was the SystemD unit file customized or are you using the stock file?

Apologies but I don’t know how to answer this one, and I don’t fully I remember how I did it then, but I think I followed a guide that copied the syncthing.service to /usr/lib/systemd/user.

While logged in as user raspi4, what’s the output from the following command?

This doesn’t seem to be working for me, here’s the output:

ls: cannot access '/media/raspi4/NVME_usb/sync_folder1/.stignore': No such file or directory

Thank you for your patience!

Debian (11/Bullseye), Ubuntu (Debian 11), Fedora and any Linux distributions based on those three already have Syncthing in their official package repositories. So if the install method was anything more complex than either of the following two commands, there’s a good chance you might have conflicting Syncthing versions and SystemD unit files.


apt install syncthing


dnf install syncthing

What’s the output from the following command?

dpkg -l | grep syncthing

Although the guide isn’t wrong, manually copying or creating a SystemD unit file isn’t necessary when using the official Syncthing Debian/Ubuntu packages because the DEB package includes a syncthing.service file that’s installed to a proper location. It’s also not necessary when using the Syncthing package from the Linux distribution.

So it’s likely that your Syncthing is being started as a service and it’s not running under user raspi4.

What’s the output from the following two commands?

systemctl status syncthing
systemctl --user status syncthing

That’s fine. I wanted to know if it would says “permission denied”, if you had an existing .stignore file, and also if your RPi was using SELinux.

You’re welcome. :slightly_smiling_face:

Can confirm it was installed this way.


ii  syncthing 1.23.4 arm64 Open Source Continuous File Synchronization


Unit syncthing.service could not be found.


● syncthing.service - Syncthing - Open Source Continuous File Synchronization
     Loaded: loaded (/usr/lib/systemd/user/syncthing.service; disabled; vendor preset: enabled)
     Active: inactive (dead)
       Docs: man:syncthing(1)

Interesting. According to SystemD, your Syncthing user service isn’t enabled and/or running.

Without changing any settings on your RPi, you can access Syncthing’s web GUI?

If so, Syncthing must be launching via some other method. Are you using one of the Syncthing wrappers? (e.g., Syncthing-GTK)

It could still be loaded as syncthing@raspi4.service instead (or any other user for that matter, in that case systemctl | grep syncthing could give an indication of how it’s loaded, if it’s loaded).

I’m curious what the result of sudo ls -la /media/raspi4/NVME_usb/sync_folder1/.stignore is. At least then we know what user owns the .stignore file and what permissions were set - which could indicate a thing or two.

Yap, the Syncthing Web UI shortcut works just fine.

I don’t believe so as I’ve only installed it via sudo apt-get install syncthing.

I’ve had no output from running systemctl | grep syncthing.

This is the output from that command:

ls: cannot access '/media/raspi4/NVME_usb/sync_folder1/.stignore': No such file or directory

It means that your RPi isn’t currently running Syncthing as a service at the system level.

If you wouldn’t mind posting the output from the following command:

systemctl status

Just a quick 101 on working with SystemD…

The following two commands are equivalent, listing system-level units that are currently running:

systemctl list-units

Display info about all running units (regardless of user):

systemctl status

Display info about all units:

systemctl status -all

Assuming that there’s a unit file named syncthing.service installed, to enable it as a system-level service:

systemctl enable syncthing.service

Because the default unit type is “service”, the .service portion isn’t required (other unit types include “mount” and “timer”). So the following command is equivalent to the previous command:

systemctl enable syncthing

Enable as a system-level service for a user named “alexa” (requires root privileges):

systemctl enable syncthing@alexa

Enable as a user-level service (no root privileges required):

systemctl --user enable syncthing

Of the three service options listed above, the systemctl --user one is generally the best for most users unless for some reason there’s a specific need to run Syncthing as root.

1 Like

As requested:

● raspberrypi
● raspberrypi
    State: running
     Jobs: 0 queued
   Failed: 0 units
    Since: Thu 1970-01-01 01:00:02 BST; 53 years 4 months ago
   CGroup: /
           │ └─user-1000.slice 
           │   ├─user@1000.service 
           │   │ ├─app.slice 
           │   │ │ ├─gvfs-goa-volume-monitor.service 
           │   │ │ │ └─1250 /usr/libexec/gvfs-goa-volume-monitor
           │   │ │ ├─pulseaudio.service 
           │   │ │ │ └─765 /usr/bin/pulseaudio --daemonize=no --log-target=journal
           │   │ │ ├─gvfs-daemon.service 
           │   │ │ │ ├─ 977 /usr/libexec/gvfsd
           │   │ │ │ ├─ 993 /usr/libexec/gvfsd-fuse /run/user/1000/gvfs -f
           │   │ │ │ ├─1278 /usr/libexec/gvfsd-trash --spawner :1.10 /org/gtk/gvfs/exec_spaw/0
           │   │ │ │ ├─1608 /usr/libexec/gvfsd-network --spawner :1.10 /org/gtk/gvfs/exec_spaw/1
           │   │ │ │ └─1631 /usr/libexec/gvfsd-dnssd --spawner :1.10 /org/gtk/gvfs/exec_spaw/3
           │   │ │ ├─gvfs-udisks2-volume-monitor.service 
           │   │ │ │ └─1208 /usr/libexec/gvfs-udisks2-volume-monitor
           │   │ │ ├─gvfs-gphoto2-volume-monitor.service 
           │   │ │ │ └─1242 /usr/libexec/gvfs-gphoto2-volume-monitor
           │   │ │ ├─gvfs-metadata.service 
           │   │ │ │ └─1291 /usr/libexec/gvfsd-metadata
           │   │ │ ├─pipewire.service 
           │   │ │ │ ├─764 /usr/bin/pipewire
           │   │ │ │ └─783 /usr/bin/pipewire-media-session
           │   │ │ ├─dbus.service 
           │   │ │ │ ├─ 778 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
           │   │ │ │ ├─1009 /usr/libexec/ibus-portal
           │   │ │ │ ├─1254 /usr/libexec/goa-daemon
           │   │ │ │ ├─1262 /usr/libexec/goa-identity-service
           │   │ │ │ └─1628 /usr/libexec/dconf-service
           │   │ │ ├─gvfs-mtp-volume-monitor.service 
           │   │ │ │ └─1232 /usr/libexec/gvfs-mtp-volume-monitor
           │   │ │ └─gvfs-afc-volume-monitor.service 
           │   │ │   └─1220 /usr/libexec/gvfs-afc-volume-monitor
           │   │ └─init.scope 
           │   │   ├─749 /lib/systemd/systemd --user
           │   │   └─750 (sd-pam)
           │   ├─session-3.scope 
           │   │ ├─ 674 /bin/login -f
           │   │ └─1484 -bash
           │   └─session-1.scope 
           │     ├─   744 lightdm --session-child 12 15
           │     ├─   766 /usr/bin/lxsession -s LXDE-pi -e LXDE -w openbox-lxde-pi
           │     ├─   932 /usr/bin/ssh-agent /usr/bin/im-launch x-session-manager
           │     ├─   949 /usr/bin/ibus-daemon --daemonize --xim
           │     ├─   995 /usr/libexec/ibus-memconf
           │     ├─   996 /usr/libexec/ibus-ui-gtk3
           │     ├─  1000 /usr/libexec/ibus-extension-gtk3
           │     ├─  1003 /usr/libexec/ibus-x11 --kill-daemon
           │     ├─  1019 openbox --config-file /home/raspi4/.config/openbox/lxde-pi-rc.xml
           │     ├─  1023 lxpolkit
           │     ├─  1024 lxpanel --profile LXDE-pi
           │     ├─  1025 pcmanfm --desktop --profile LXDE-pi
           │     ├─  1036 /usr/bin/ssh-agent -s
           │     ├─  1044 /usr/libexec/at-spi-bus-launcher --launch-immediately
           │     ├─  1046 xcompmgr -aR
           │     ├─  1056 /usr/bin/syncthing serve --no-browser --logfile=default
           │     ├─  1062 nm-applet
           │     ├─  1074 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3
           │     ├─  1089 /usr/bin/syncthing serve --no-browser --logfile=default
           │     ├─  1109 /usr/libexec/at-spi2-registryd --use-gnome-session
           │     ├─  1206 /usr/libexec/ibus-engine-simple
           │     ├─  1227 /usr/lib/menu-cache/menu-cached /run/user/1000/menu-cached-:0
           │     ├─163924 lxterminal
           │     ├─163930 bash
           │     ├─164003 systemctl status
           │     └─164004 pager
           │ └─1 /sbin/init splash
             │ └─1692 /usr/libexec/packagekitd
             │ └─180 /lib/systemd/systemd-udevd
             │ └─451 /usr/sbin/thd --triggers /etc/triggerhappy/triggers.d/ --socket /run/thd.socket --user nobody --deviceglob /dev/input/event*
             │ └─428 /usr/sbin/cron -f
             │ └─serial-getty@ttyAMA0.service 
             │   └─678 /sbin/agetty -o -p -- \u --keep-baud 115200,57600,38400,9600 ttyAMA0 vt220
             │ └─434 /usr/libexec/polkitd --no-debug
             │ └─776 /usr/libexec/rtkit-daemon
             │ └─426 /usr/libexec/accounts-daemon
             │ └─458 /sbin/wpa_supplicant -u -s -O /run/wpa_supplicant
             │ ├─604 /usr/sbin/lightdm
             │ └─673 /usr/lib/xorg/Xorg :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
             │ └─596 /usr/sbin/ModemManager
             │ └─788 /usr/bin/perl /usr/share/webmin/miniserv.pl /etc/webmin/miniserv.conf
             │ └─153 /lib/systemd/systemd-journald
             │ ├─ 572 /usr/bin/vncserver-x11-serviced -fg
             │ ├─ 587 /usr/bin/vncserver-x11-core -service
             │ ├─ 680 /usr/bin/vncagent service 0
             │ ├─1080 /usr/bin/vncserverui service 0
             │ └─1085 /usr/bin/vncserverui -statusicon 0
             │ └─445 /usr/libexec/switcheroo-control
             │ └─443 /usr/sbin/rsyslogd -n -iNONE
             │ ├─486 /usr/sbin/dhcpcd -b -q
             │ └─608 wpa_supplicant -B -c/etc/wpa_supplicant/wpa_supplicant.conf -iwlan0
             │ └─525 /usr/sbin/rngd -r /dev/hwrng
             │ └─36688 /usr/sbin/cups-browsed
             │ └─36686 /usr/sbin/cupsd -l
             │ └─162176 /usr/libexec/upowerd
             │ └─452 /usr/libexec/udisks2/udisksd
             │ └─429 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
             │ └─344 /lib/systemd/systemd-timesyncd
             │ ├─427 avahi-daemon: running [raspberrypi.local]
             │ └─453 avahi-daemon: chroot helper
               └─449 /lib/systemd/systemd-logind
lines 89-135/135 (END)

Apologies, should I do any of these steps? And thank you for the breakdown! :smiley:

No problem, the other commands were just for future reference and hopefully to help with understanding SystemD a little bit more.

According to your output from systemctl status, you’ve got a user with UID 1000 running Syncthing. However, it’s not running as a service. Here’s a snippet:

           │   └─session-1.scope 
           │     ├─   744 lightdm --session-child 12 15
           │     ├─   766 /usr/bin/lxsession -s LXDE-pi -e LXDE -w openbox-lxde-pi
           │     ├─   932 /usr/bin/ssh-agent /usr/bin/im-launch x-session-manager
           │     ├─   949 /usr/bin/ibus-daemon --daemonize --xim
           │     ├─   995 /usr/libexec/ibus-memconf
           │     ├─   996 /usr/libexec/ibus-ui-gtk3
           │     ├─  1000 /usr/libexec/ibus-extension-gtk3
           │     ├─  1003 /usr/libexec/ibus-x11 --kill-daemon
           │     ├─  1019 openbox --config-file /home/raspi4/.config/openbox/lxde-pi-rc.xml
           │     ├─  1023 lxpolkit
           │     ├─  1024 lxpanel --profile LXDE-pi
           │     ├─  1025 pcmanfm --desktop --profile LXDE-pi
           │     ├─  1036 /usr/bin/ssh-agent -s
           │     ├─  1044 /usr/libexec/at-spi-bus-launcher --launch-immediately
           │     ├─  1046 xcompmgr -aR
           │     ├─  1056 /usr/bin/syncthing serve --no-browser --logfile=default
           │     ├─  1062 nm-applet
           │     ├─  1074 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3
           │     ├─  1089 /usr/bin/syncthing serve --no-browser --logfile=default
           │     ├─  1109 /usr/libexec/at-spi2-registryd --use-gnome-session
           │     ├─  1206 /usr/libexec/ibus-engine-simple
           │     ├─  1227 /usr/lib/menu-cache/menu-cached /run/user/1000/menu-cached-:0
           │     ├─163924 lxterminal
           │     ├─163930 bash
           │     ├─164003 systemctl status
           │     └─164004 pager

Note how /usr/bin/syncthing (process ID 1056 and 1089) is running at the same level in the process tree as nm-applet (PID 1062). It’s also at the same process level as when you issued the command systemctl status. It means it’s part of your desktop session, so whenever you log off Syncthing shuts down.

Does the following file exist on your RPi?


And speaking of UID 1000, although it likely is, just to be certain, confirm that raspi4 is UID 1000 (-n replaces the default user and group names with their respective UID and GID):

ls -ln /media/raspi4/NVME_usb/
1 Like

No, it does not. The /home/raspi4/.config/systemd/user/ folder is empty.

Output of ls -ln /media/raspi4/NVME_usb/ as requested:

total 32
drwxr-xr-x 5 1000 1000  4096 Apr 30 13:44 sync_folder1
drwxr-xr-x 3 1000 1000  4096 Apr 30 18:43 sync_folder2
drwxr-xr-x 7 1000 1000  4096 Apr 30 13:27 sync_folder3
drwxr-xr-x 4 1000 1000  4096 Apr 30 13:26 sync_folder4
drwx------ 2    0    0 16384 Apr 24 16:24 lost+found

Not sure if related but I do have syncthing-start.desktop on /home/raspi4/.config/autostart if that helps.

So that definitively confirms systemctl --user hasn’t been used to set up any user services.

That’s good. The UID and GID match the user running Syncthing.

There’s nothing wrong with launching Syncthing that way. If you always stay logged onto the desktop it’s effectively the same end result as running it via SystemD, initd, or some other method. So now that we know SystemD isn’t involved, we can ignore it.

Since we’ve confirmed that Syncthing is running under user raspi4, and that the same user is also the owner of /media/raspi4/NVME_usb/sync_folder1, there should be no issue creating a .stignore file. So try the following command which will create an empty file:

touch `/media/raspi4/NVME_usb/sync_folder1/.stignore`

If the command above fails, there’s a good chance that the filesystem on your SSD might be corrupted. Is your USB device a NVMe stick in a USB adapter?

Result of the output above:

bash: /media/raspi4/NVME_usb/sync_folder1/.stignore: No such file or directory
touch: missing file operand
Try 'touch --help' for more information.

Yes, it’s an NVMe on a USB enclosure. However, outside of this the drive seems to be fine and working properly? I can access all its data, and checking the filesystem using Disks doesn’t result in any issues or errors either. I had also formatted it to Ext4 filesystem from the get go in hopes this would be more compatible and less error prone in the future.

I keep seeing this on boot on the yellow Notice modal:

2023-05-03 20:54:31: Error on folder "sync_folder1" (sync_folder1): folder path missing
2023-05-03 20:54:31: Error on folder "sync_folder2" (sync_folder2): folder path missing
2023-05-03 20:54:31: Error on folder "sync_folder3" (sync_folder3): folder path missing
2023-05-03 20:54:31: Error on folder "sync_folder4" (sync_folder4): folder path missing

oops… I just noticed that I’d unintentionally included back ticks in the example command, resulting in the “missing file operand” error. Let’s try that again:

touch /media/raspi4/NVME_usb/sync_folder1/.stignore

Too soon to tell if it’s certainly a filesystem problem. Depends on the result of the touch command above.

As long as there aren’t millions of files and directories, ext4 is a good choice.

For SSDs, btrfs is also well worth considering because it has some flash media friendly and extra data integrity features.

You’ve got a bit of a chicken-and-egg problem.

On Debian-based Linux distros, if there’s a desktop environment, removable media is auto-mounted under /media/<user>/<volume_label> (if there’s no volume label, the manufacturer name is often used instead).

Because the auto-mounter depends on you logging onto the desktop first, the path /media/raspi4/NVME_usb/ doesn’t exist yet – even if the USB drive is already plugged in.

And because /home/raspi4/.config/autostart/syncthing-start.desktop is part of your list of auto-started apps at login, Syncthing could potentially launch before `/media/raspi4/NVME_usb/sync_folder1" is actually available.

No output results from running that command.

I do have multiple Cryptomator vaults which tends to break things into a million pieces so I wonder if it could be related? At least I have some out of sync items failing with the following error:

invalid length scan: Time.UnmarshalBinary: invalid length

One to consider if I ever decide to nuke everything and start from scratch.

Open to suggestions! I’ve always had a Windows <-> Windows and a Windows <-> Mac setup and I’ve never had any issues, but now I’ve tried to move away from that by setting up a Raspberry Pi running Linux as a server to which both Windows and Mac sync to.

Even through it’s not ideal, I’m starting to consider re-imaging the system and start from scratch at this point, but I would need to be sure to set everything properly this time around to avoid coming across this or other future issues. Having that said, I would still obviously rather being able to simply fix my currents issues.

This is one of those “no news is good news” things. touch is normally silent except when there’s an error.

Because the command was successful, it means that there’s no permissions issue as long as syncthing is running under the same user you were logged on as for touch (which I’m assuming is “raspi4”).

It sounds like a bad time value was returned when Syncthing tried to read a file’s metadata. Having run across bit rot more than once before, I’d be concerned about filesystem corruption.

The backup program I use also dices up files into small chunks so in the past I’ve exhausted the number of inodes on a storage volume.

If you don’t already know which device node your USB NVMe is on:

df -h

Since RPi users usually boot from a SD card, your USB NVMe is probably at /dev/sda. And chances are there’s only one partition, so to get details about an ext2/3/4 volume:

tune2fs -l /dev/sda1

Check the “Inode count” and “Free inodes” values. Generally speaking, the total expected file count to be stored in the volume must be less than the inode count.

Ext2/3/4 pre-allocates a fixed number of inodes during formatting while btrfs creates them on-demand (limit is 264 inodes per subvolume – a disk partition can contain multiple subvolumes).

btrfs checksums every block written, so to start, cancel or status check a checksum verification:

btrfs scrub start /dev/sda1
btrfs scrub cancel /dev/sda1
btrfs scrub status /dev/sda1

On Windows, its StartUp folder is roughly equivalent to ~/.config/autostart/ on Linux.

When plugging a USB drive into Windows, it’s assigned a drive letter independent of any user desktop sessions. So by the time you log onto Windows and Syncthing is started via the StartUp folder, the USB drive is already available – to every user on the computer.

In contrast, desktop environments on Linux normally auto-mount a USB drive only after a user has logged on. It provides privacy and security on a multi-user system because the USB drive won’t immediately be accessible by every user on the computer.

(Last time I checked, macOS has similar behavior to Windows with regards to removable media.)

Without knowing what your workflow is like on your RPi – e.g., how often is your USB NVMe unplugged? – recommending a particular solution isn’t easy.

One suggestion is to simply not auto-start Syncthing. Make it part of your desktop routine instead:

  1. Log on.
  2. Plug in your USB NVMe.
  3. Launch Syncthing (tip: launch in a terminal window so Syncthing’s activity log is visible. Just minimize the window when not needed).
  4. Shut down Syncthing (or just close the terminal window).
  5. Log off.
  6. Unplug the USB NVMe.

(It’s actually what I do on my laptop.)

For Linux there are often multiple solutions to just about anything one can think of.

On my home NAS, I have Syncthing started by SystemD, but on a 15-minute time delay. Whenever the NAS is rebooted after OS updates there’s time for Linux to mount and check various storage volumes first.

Because you’re using your RPi as a server for your Windows and Mac devices, and if your USB NVMe isn’t frequently being unplugged, I’d use an /etc/fstab entry so that the USB NVMe is mounted at boot time instead of at user desktop login time.

It looks like your ext4 volume has the label “NVME_usb”, so first create the mount point…

mkdir /mnt/NVME_usb

… then add the following line to /etc/fstab:

LABEL=NVME_usb    /mnt/NVME_usb   ext4    defaults,noatime,nodev,nosuid,discard,uid=1000,gid=1000 0 0

Breaking it down…

  • LABEL=NVME_usb tells Linux to find a device volume with the specified label. Although a device node (e.g. /dev/sda1) also works instead of LABEL=NVME_usb, the latter is more flexible in case more drives are added (trying to keep track of which removable drive is on which device node gets messier the more drives there are).
  • /mnt/NVME_usb is a suitable mount point. Although you technically could use /media/raspi4/NVME_usb, the auto-mounter manages /media/raspi4 so there could be conflicts and it’s just cleaner to use `/mnt’.
  • ext4 specifies the filesystem type.
  • defaults … yup, accepting the defaults, then overriding some of them.
  • noatime disables recording the access time everytime a file is touched. Most users don’t need the info, it reduces wear on flash media, and it improves read times.
  • nodev says no character and/or block special devices (optional).
  • nosuid says no setuid files for better security (optional).
  • discard enables TRIM for use with SSD drives.
  • uid=1000 temporarily makes /mnt/NVME_usb owned by the user with UID 1000 (“raspi4” on your RPi).
  • gid=1000 temporarily makes /mnt/NVME_usb owned by the group with GID 1000 (“raspi4” on your RPi).
  • 0 is don’t dump at mount time.
  • 0 is no fsck at mount time (ext4 is a journaling filesystem, so unless journaling is disabled, better to do a fsck offline as needed).

Now you can leave Syncthing to auto-start when the user desktop loads because your USB NVMe will already be available early during the boot process.