This is reflected in samba log:
[2019/03/26 10:23:26.292959, 2] …/source3/smbd/vfs.c:1392(check_reduced_name)
check_reduced_name: Bad access attempt: . is a symlink outside the share path
conn_rootdir =/mnt2/xkrejci/./.xkrejci_201903251630
resolved_name=/mnt2/xkrejci/.xkrejci_201903251630/drive/Temp
[2019/03/26 10:23:26.293078, 3] …/source3/smbd/smb2_server.c:3171(smbd_smb2_request_error_ex)
smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_ACCESS_DENIED] || at …/source3/smbd/smb2_create.c:296
[2019/03/26 10:23:26.300961, 2] …/source3/smbd/vfs.c:1392(check_reduced_name)
check_reduced_name: Bad access attempt: Temp is a symlink outside the share path
conn_rootdir =/mnt2/xkrejci/./.xkrejci_201903251630
resolved_name=/mnt2/xkrejci/.xkrejci_201903251630/drive/Temp
[2019/03/26 10:23:26.301046, 3] …/source3/smbd/open.c:1261(open_file)
Error opening file @GMT-2019.03.25-15.30.00/drive/Temp (NT_STATUS_ACCESS_DENIED) (local_flags=0) (flags=0)
[2019/03/26 10:23:26.301101, 3] …/source3/smbd/smb2_server.c:3171(smbd_smb2_request_error_ex)
smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_ACCESS_DENIED] || at …/source3/smbd/smb2_create.c:296
[2019/03/26 10:23:28.089402, 3] …/source3/smbd/service.c:1120(close_cnum)
spravce-it (ipv4:10.20.51.11:6483) closed connection to service IPC$
Snapshots are created automatically using the Task Scheduler. My Rockstor version is 3.9.2-47 (Stable Channel). I did make any special configuration changes - I have only created the shares, samba exports and scheduled the snapshots.
Hello @vesper1978,
thank you for your reply.
I have checked samba config, but there is no line with the “follow symlinks = no” (there is even no line with “follow symlinks = yes”).
Finally, I have found the solution. I have added these two configuration options to the global section of samba configuration file:
unix extensions = no
wide links = yes
Now the I can access the previous version from Windows clients (we have no unix clients, so I can’t test this). Since we have no unix clients, this is ok for me, but I am wondering, if this is intended Rockstor behaviour.
@Lukas Hello again and well done on finally tracking down the reason for this issue. Nice find.
I’m not up on these config options myself but given this has been a widely experienced problem, linking to your prior post in a thread involving @Mahmoud87, @Flyer, @Hooverdan, @TheFox, @Larry_Gilmore:
can we have some others input on if we need to enable these options by default in Rockstor’s samba config.
That would be a great thing to get sorted and I’m happy to sort it but need more input on if this is the right thing to do.
Thank again for sharing your fix and persevering with this problem, and for helping to support Rockstor’s development via a stable subscription.
@vesper1978 Thanks for the smb.conf config option prompting on this issue; any thoughts on if we should incorporate @Lukas’s findings by default?
I’m tending towards having the unix extensions configurable via the Web-UI but we should be mindful of not cluttering / complicating our user experiences as without that we end up putting all know options in the Web-UI and creating a monster of a UI / UX. Don’t know the consequences of persistent (default) ‘wide links = yes’ however.
All informed input welcome here. We can then create an issue on the consensus and to get this one sorted ‘out of the box’.
The “wide links = yes” allows for following symbolic links that point outside the directory tree. Which, with how snapshots are done with btrfs it’s possible for the “previous version” to exist outside of the directory tree for the share. However, you can’t set that safely without also settings “unix extensions = no”.
The “unix extensions = no” would break some UNIX CIFS clients. But, I doubt there’s going to be many of those seen these days.
My suggestion is to add both to the Samba Export if “Enable Shadow Copy?” is checked, and remove them when the check is removed.
In essence, one could possibly connect to the root filesystem from any share exported with these options.
Yikes.
I did some digging, and it appears to be some form of regression. I am not sure it is specific to btrfs, but I am encountering the same problem with btrfs.
