I decided to update my home server setup from a pi3 running dietpi to a desktop for some more power. I enjoyed the ease of dietpi and saw it could run in virtualbox. So I have a host machine running virtualbox on linux mint, there is a VM_Share folder that I have setup that both the host and guest can access. I have syncthing running on both the old dietpi on the physical pi, and on virtual dietpi to transfer media over (I plan to continue to use the old pi as a backup with syncthing, but offload every other task). Syncthing is throwing permission denied errors when trying to write to the new location.
Because there are in effect 3 locations that permissions can be set, it can get a little confusing. There’s the old dietpi, the new dietpi running as a guest VM, and the host Mint OS where the folder actually resides. The Host shows the folder permission as 775 and is owned by the primary user account running the VM. The Guest is showing folder permissions as 775 and owned by root. If I change the permissions on the host to 777, it reflects in the VM and syncthing starts to transfer files. However, once syncthing creates a folder, that folder’s permissions are set to 775 and syncthing can not access it to put files inside.
To make the share between the host and guest work with virtualbox, the guest installs a virtual network connection connection to the host with the mount type being vboxsf. I’ve ensured that the dietpi user is a member of the vboxsf group and that the vboxadd user is a member of the dietpi group. I do not see a syncthing user or group, so I presume that is not a part of the equation. On the host, I’ve ensured that the primary user running the VM is a member of vboxusers. So it seems to me that there should be enough permission for a user or group member to write to the share without needing the ‘other’ write flag set.
I’ve done a work around by setting a cron job to chmod -R the media folder to 777 every 10 minutes to get the data moving. While I’m not concerned as much about the security aspect of this, it’s not really a graceful or efficient solution, and I would really like to understand why I’m having the trouble with syncthing. Especially if this issue is mirrored with the other functions of the server, like the downloading of media.
many thanks for your request. If I get it right, you would need Syncthing to create folders with 777 permissions. correct?
Basically if Syncthing created a folder, how does file system permission/owner/group looks like on the other systems?
Thanks for the reply.
Changing syncthing to write files/folders as 777 would be one way certainly, but not the ideal way. I’m trying to figure out why the current owner/group permissions are not sufficient that require me to resort to the use of allowing write access to ‘other’. What account or group does syncthing use on dietpi to perform it’s functions on linux?
Sorry My last reply didn’t address this.
If syncthing creates a folder, that folder will appear on the destination dietpi as owned by user and group root with 775. If I look on the host system, it shows the primary username as both the owner and group.
can you share a df -h from both systems showing the folder in question?
$ df -h /media/crossmenx/DeepStorage/VM_Share/Video/tv
Filesystem Size Used Avail Use% Mounted on
/dev/sdb 5.5T 486G 4.7T 10% /media/crossmenx/DeepStorage
# df -h /mnt/VM_Share/Video/tv
Filesystem Size Used Avail Use% Mounted on
VM_Share 5.5T 766G 4.7T 14% /mnt/VM_Share
Ahh sorry my mistake. I would like to see ls -la and not df. Sorry for confusion
No worries, here ya go!
crossmenx@CinePlex:~$ ls -la /media/crossmenx/DeepStorage/VM_Share/Video/tv
drwxrwxrwx 73 crossmenx crossmenx 4096 Jun 20 19:07 .
drwxrwxrwx 4 crossmenx crossmenx 4096 Jun 20 18:15 …
drwxrwxrwx 6 crossmenx crossmenx 4096 Jun 23 19:27 ‘TV Show 1’
drwxrwxrwx 3 crossmenx crossmenx 4096 Jun 23 19:27 ‘TV Show 2’
drwxrwxrwx 8 crossmenx crossmenx 4096 Jun 23 19:27 ‘TV Show 3’
drwxrwxrwx 3 crossmenx crossmenx 4096 Jun 23 19:27 ‘TV Show 4’
root@DietPi2:~# ls -la /mnt/VM_Share/Video/tv
drwxrwxrwx 1 root root 4096 Jun 21 03:07 .
drwxrwxrwx 1 root root 4096 Jun 21 02:15 …
drwxrwxrwx 1 root root 4096 Jun 24 03:27 ‘TV Show 1’
drwxrwxrwx 1 root root 4096 Jun 24 03:27 ‘TV Show 2’
drwxrwxrwx 1 root root 4096 Jun 24 03:27 ‘TV Show 3’
drwxrwxrwx 1 root root 4096 Jun 24 03:27 ‘TV Show 4’
Changed the folder names on here out of caution shruggs. Also as stated in the original post, the work around I have is to run a cron to change the permissions every 10 minutes, so what you see is the working state, otherwise it’d be showing as: drwxrwxr-x for both files and folders though owner:group remains the same
ok your problem is, that Syncthing is running under user dietpi. Therefore Syncthing is not able to access the folder belonging to root user/group as long as you did not change it to 777. Looks like every file/folder that’s created on this mount point belongs to root. Probably due to the way how it’s mounted.
root@DietPiVM1:/home/dietpi# ps -ef |grep sync
dietpi 619 1 0 00:31 ? 00:00:00 /opt/syncthing/syncthing -no-browser -no-restart -logflags=0 -home=/mnt/dietpi_userdata/syncthing
dietpi 644 619 0 00:31 ? 00:00:08 /opt/syncthing/syncthing -no-browser -no-restart -logflags=0 -home=/mnt/dietpi_userdata/syncthing
To work around, you could force Syncthing running as root or you check within /etc/fstab how the mount is done for this file system. Maybe you could have it mounted using user dietpi?
You were right on the /etc/fstab
The guide I followed to mount the hosts shared folder within the virtualbox guest system didn’t cover changing the uid/gid in /etc/fstab so it was just root by default. I’ve removed my cron job, and am waiting for syncthing to transfer new files to verify, but it’s slow and I suspect you solved it. Thank you again!
Edit: for those who find themselves in the same position my /etc/fstab has the following line:
VM_Share /mnt/VM_Share vboxsf defaults,uid=1000,gid=1000 0 0
Where VM_Share is the name of the folder and may be different for you.
ok I mark the topic as solved for now.