Hi,
I have started using symbolic links on an SMB share and find that
symbolic links whose target no longer exists cannot be removed on the
client side.
Example, on the SMB client side in an SMB-mounted directory:
1. Create a file and a relative symlink to it:
$ touch a
$ ln -s a b
$ ls -l
total 0
-rw-rw-r--. 1 andi andi 0 Jan 6 14:42 a
lrwxrwxrwx. 1 andi andi 1 Jan 6 14:42 b -> a
2. Removing the symlink target causes removal of symlink to fail:
$ rm a
$ ls -l
total 0
lrwxrwxrwx. 1 andi andi 1 Jan 6 14:42 b -> a
# With colors on, the b and a are now marked red, indicating a
broken symlink
$ rm b
rm: cannot remove ‘b’: No such file or directory
$ ls -l
total 0
lrwxrwxrwx. 1 andi andi 1 Jan 6 14:42 b -> a
3. Reestablishing the symlink target causes removal of symlink to work
again:
$ touch a
$ ls -l
total 0
-rw-rw-r--. 1 andi andi 0 Jan 6 14:44 a
lrwxrwxrwx. 1 andi andi 1 Jan 6 14:42 b -> a
$ rm b
$ ls -l
total 0
-rw-rw-r--. 1 andi andi 0 Jan 6 14:44 a
The same test when performed on a local file system, works fine (i.e.
the broken symlink can successfully be removed).
I have debugged this on the server side by enabling debug logs in the
Synology NAS, and the relevant portion during the "rm b" command on
the
broken symlink is (the directory is Projects/xx/try1, relative to the
SMB share):
../source3/smbd/process.c:1823: [2016/01/06 16:01:50.101627, all 3,
pid=17490] process_smb
Transaction 495774 of length 116 (0 toread)
../source3/smbd/process.c:1422: [2016/01/06 16:01:50.101795, all 3,
pid=17490] switch_message
switch message SMBtrans2 (pid 17490) conn 0xf78384a0
../source3/smbd/trans2.c:5419: [2016/01/06 16:01:50.101919, all 3,
pid=17490] call_trans2qfilepathinfo
call_trans2qfilepathinfo: TRANSACT2_QPATHINFO: level = 512
../source3/smbd/trans2.c:5562: [2016/01/06 16:01:50.102076, all 3,
pid=17490] call_trans2qfilepathinfo
call_trans2qfilepathinfo Projects/xx/try1/b (fnum [fsp is NULL])
level=512 call=5 total_data=0
../source3/smbd/process.c:1823: [2016/01/06 16:01:50.103166, all 3,
pid=17490] process_smb
Transaction 495775 of length 120 (0 toread)
../source3/smbd/process.c:1422: [2016/01/06 16:01:50.103370, all 3,
pid=17490] switch_message
switch message SMBtrans2 (pid 17490) conn 0xf78384a0
../source3/smbd/trans2.c:8435: [2016/01/06 16:01:50.103517, all 3,
pid=17490] call_trans2setfilepathinfo
call_trans2setfilepathinfo(6) Projects/xx/try1/b (fnum [fsp is NULL])
info_level=522 totdata=2
../source3/smbd/trans2.c:7989: [2016/01/06 16:01:50.103611, all 3,
pid=17490] smbd_do_setfilepathinfo
smbd_do_setfilepathinfo: Projects/xx/try1/b (fnum [fsp is NULL])
info_level=522 totdata=2
../source3/smbd/open.c:1194: [2016/01/06 16:01:50.103800, all 2,
pid=17490] open_file
andi opened file Projects/xx/try1/b read=No write=No (numopen=1)
../source3/modules/vfs_recycle.c:798: [2016/01/06 16:01:50.104129,
(custom) 3, pid=17490] recycle_unlink
andi have no permission (0x0) delete file [Projects/xx/try1/b]
NT_STATUS_OBJECT_NAME_NOT_FOUND
../source3/smbd/notify_internal.c:633: [2016/01/06 16:01:50.104271, all
1, pid=17490] notify_trigger
Bypass notify_trigger
../source3/smbd/close.c:831: [2016/01/06 16:01:50.104368, all 2,
pid=17490] close_normal_file
andi closed file Projects/xx/try1/b (numopen=0)
NT_STATUS_OBJECT_NAME_NOT_FOUND
../source3/smbd/error.c:82: [2016/01/06 16:01:50.104500, all 3,
pid=17490] error_packet_set
NT error packet at ../source3/smbd/trans2.c(8480) cmd=50 (SMBtrans2)
NT_STATUS_OBJECT_NAME_NOT_FOUND
Note the line with "andi have no permission". Could this be a
permission
problem? However, on the server side, the file system permissions look good.
-> Any ideas about the root cause and how to resolve it?
Or how to debug it further?
Andy
===================================
Data about the environment:
Client:
* Virtual CentOS 7 client (on VirtualBox on Windows 7) using cifs-utils
6.2 and kernel 3.10.0
* Mount: Via /etc/fstab, the entry looks like:
//ds12/home /media/ds12_home_andi cifs
credentials=/home/andi/.ds12cred,forceuid,uid=andi,forcegid,gid=users,noserverino
0 0
The mount command provides somewhat more information:
//ds12/home on /media/ds12_home_andi type cifs
(rw,relatime,vers=1.0,cache=strict,username=andi,domain=WORKGROUP,uid=1000,forceuid,gid=100,forcegid,addr=192.168.0.12,unix,posixpaths,acl,rsize=1048576,wsize=1048576,actimeo=1)
* /proc/fs/cifs/DebugData for this share:
Display Internal CIFS Data Structures for Debugging
---------------------------------------------------
CIFS Version 2.03
Features: dfs lanman posix spnego xattr acl
Active VFS Requests: 0
Servers:
1) Name: 192.168.0.12 Domain: WORKGROUP Uses: 1 OS: Unix
NOS: Samba 4.1.18 Capability: 0x8080f3fd
SMB session status: 1 TCP status: 1
Local Users To Server: 2 SecMode: 0x3 Req On Wire: 0
Shares:
1) \\ds12\home Mounts: 1 Type: NTFS DevInfo: 0x20 Attributes:
0x50027
PathComponentMax: 255 Status: 0x1 type: DISK
MIDs:
Server:
* Synology NAS server with DSM 5.2-5644 Update 2 (which uses samba, I
assume the client's DebugData file shows the version of samba on the
server: 4.1.18).
* Symbolic link support is enabled in the SMB options in the DSM user
interface. The relevant portions of the /usr/syno/etc/smb.conf file
(Synology uses BusyBox) are:
[global]
printcap name=cups
winbind enum groups=yes
ldap admin dn=uid=root,cn=users,dc=am,dc=org
encrypt passwords=yes
ldap ssl=Off
security=user
local master=no
realm=*
ldap passwd sync=yes
ldap suffix=dc=am,dc=org
passdb backend=multi:smbpasswd,ldapsam:ldap://localhost
syno ldap support=yes
printing=cups
max protocol=SMB2_10
winbind enum users=yes
load printers=yes
workgroup=WORKGROUP
[home]
create mode = 0777
comment = home
browseable = no
writable = yes
valid users = %U
directory mode = 0777
path = /var/services/homes/%U
[homes]
invalid users=nobody,nobody
valid users=nobody,nobody
comment="User homes (mount 'home')"
path=/volume2/homes
guest ok=yes
browseable=no
fileindex=no
mediaindex=yes
edit synoacl=yes
win share=yes
skip smb perm=yes
enable recycle bin=yes
recycle bin admin only=no
hide unreadable=no
ftp disable list=no
ftp disable modify=no
ftp disable download=no
read list=nobody,nobody
write list=nobody,nobody
writeable=yes
====================================
On 06/01/16 17:36, Andreas Maier wrote:> Hi, > I have started using symbolic links on an SMB share and find that > symbolic links whose target no longer exists cannot be removed on the > client side. > > Example, on the SMB client side in an SMB-mounted directory: > > 1. Create a file and a relative symlink to it: > > $ touch a > $ ln -s a b > $ ls -l > total 0 > -rw-rw-r--. 1 andi andi 0 Jan 6 14:42 a > lrwxrwxrwx. 1 andi andi 1 Jan 6 14:42 b -> a > > 2. Removing the symlink target causes removal of symlink to fail: > > $ rm a > $ ls -l > total 0 > lrwxrwxrwx. 1 andi andi 1 Jan 6 14:42 b -> a > # With colors on, the b and a are now marked red, indicating a > broken symlink > $ rm b > rm: cannot remove ‘b’: No such file or directory > $ ls -l > total 0 > lrwxrwxrwx. 1 andi andi 1 Jan 6 14:42 b -> a > > 3. Reestablishing the symlink target causes removal of symlink to work > again: > > $ touch a > $ ls -l > total 0 > -rw-rw-r--. 1 andi andi 0 Jan 6 14:44 a > lrwxrwxrwx. 1 andi andi 1 Jan 6 14:42 b -> a > $ rm b > $ ls -l > total 0 > -rw-rw-r--. 1 andi andi 0 Jan 6 14:44 a > > The same test when performed on a local file system, works fine (i.e. > the broken symlink can successfully be removed). > > I have debugged this on the server side by enabling debug logs in the > Synology NAS, and the relevant portion during the "rm b" command on > the broken symlink is (the directory is Projects/xx/try1, relative to > the SMB share): > > ../source3/smbd/process.c:1823: [2016/01/06 16:01:50.101627, all 3, > pid=17490] process_smb > Transaction 495774 of length 116 (0 toread) > ../source3/smbd/process.c:1422: [2016/01/06 16:01:50.101795, all 3, > pid=17490] switch_message > switch message SMBtrans2 (pid 17490) conn 0xf78384a0 > ../source3/smbd/trans2.c:5419: [2016/01/06 16:01:50.101919, all 3, > pid=17490] call_trans2qfilepathinfo > call_trans2qfilepathinfo: TRANSACT2_QPATHINFO: level = 512 > ../source3/smbd/trans2.c:5562: [2016/01/06 16:01:50.102076, all 3, > pid=17490] call_trans2qfilepathinfo > call_trans2qfilepathinfo Projects/xx/try1/b (fnum [fsp is NULL]) > level=512 call=5 total_data=0 > > ../source3/smbd/process.c:1823: [2016/01/06 16:01:50.103166, all 3, > pid=17490] process_smb > Transaction 495775 of length 120 (0 toread) > ../source3/smbd/process.c:1422: [2016/01/06 16:01:50.103370, all 3, > pid=17490] switch_message > switch message SMBtrans2 (pid 17490) conn 0xf78384a0 > ../source3/smbd/trans2.c:8435: [2016/01/06 16:01:50.103517, all 3, > pid=17490] call_trans2setfilepathinfo > call_trans2setfilepathinfo(6) Projects/xx/try1/b (fnum [fsp is > NULL]) info_level=522 totdata=2 > ../source3/smbd/trans2.c:7989: [2016/01/06 16:01:50.103611, all 3, > pid=17490] smbd_do_setfilepathinfo > smbd_do_setfilepathinfo: Projects/xx/try1/b (fnum [fsp is NULL]) > info_level=522 totdata=2 > ../source3/smbd/open.c:1194: [2016/01/06 16:01:50.103800, all 2, > pid=17490] open_file > andi opened file Projects/xx/try1/b read=No write=No (numopen=1) > ../source3/modules/vfs_recycle.c:798: [2016/01/06 16:01:50.104129, > (custom) 3, pid=17490] recycle_unlink > andi have no permission (0x0) delete file [Projects/xx/try1/b] > NT_STATUS_OBJECT_NAME_NOT_FOUND > ../source3/smbd/notify_internal.c:633: [2016/01/06 16:01:50.104271, > all 1, pid=17490] notify_trigger > Bypass notify_trigger > ../source3/smbd/close.c:831: [2016/01/06 16:01:50.104368, all 2, > pid=17490] close_normal_file > andi closed file Projects/xx/try1/b (numopen=0) > NT_STATUS_OBJECT_NAME_NOT_FOUND > ../source3/smbd/error.c:82: [2016/01/06 16:01:50.104500, all 3, > pid=17490] error_packet_set > NT error packet at ../source3/smbd/trans2.c(8480) cmd=50 (SMBtrans2) > NT_STATUS_OBJECT_NAME_NOT_FOUND > > Note the line with "andi have no permission". Could this be a > permission problem? However, on the server side, the file system > permissions look good. > > -> Any ideas about the root cause and how to resolve it? > Or how to debug it further? > > Andy > > ===================================> > Data about the environment: > > Client: > > * Virtual CentOS 7 client (on VirtualBox on Windows 7) using > cifs-utils 6.2 and kernel 3.10.0 > > * Mount: Via /etc/fstab, the entry looks like: > > //ds12/home /media/ds12_home_andi cifs > credentials=/home/andi/.ds12cred,forceuid,uid=andi,forcegid,gid=users,noserverino > 0 0 > > The mount command provides somewhat more information: > > //ds12/home on /media/ds12_home_andi type cifs > (rw,relatime,vers=1.0,cache=strict,username=andi,domain=WORKGROUP,uid=1000,forceuid,gid=100,forcegid,addr=192.168.0.12,unix,posixpaths,acl,rsize=1048576,wsize=1048576,actimeo=1) > > * /proc/fs/cifs/DebugData for this share: > > Display Internal CIFS Data Structures for Debugging > --------------------------------------------------- > CIFS Version 2.03 > Features: dfs lanman posix spnego xattr acl > Active VFS Requests: 0 > Servers: > 1) Name: 192.168.0.12 Domain: WORKGROUP Uses: 1 OS: Unix > NOS: Samba 4.1.18 Capability: 0x8080f3fd > SMB session status: 1 TCP status: 1 > Local Users To Server: 2 SecMode: 0x3 Req On Wire: 0 > Shares: > 1) \\ds12\home Mounts: 1 Type: NTFS DevInfo: 0x20 Attributes: > 0x50027 > PathComponentMax: 255 Status: 0x1 type: DISK > > MIDs: > > Server: > > * Synology NAS server with DSM 5.2-5644 Update 2 (which uses samba, I > assume the client's DebugData file shows the version of samba on the > server: 4.1.18). > > * Symbolic link support is enabled in the SMB options in the DSM user > interface. The relevant portions of the /usr/syno/etc/smb.conf file > (Synology uses BusyBox) are: > > [global] > printcap name=cups > winbind enum groups=yes > ldap admin dn=uid=root,cn=users,dc=am,dc=org > encrypt passwords=yes > ldap ssl=Off > security=user > local master=no > realm=* > ldap passwd sync=yes > ldap suffix=dc=am,dc=org > passdb backend=multi:smbpasswd,ldapsam:ldap://localhost > syno ldap support=yes > printing=cups > max protocol=SMB2_10 > winbind enum users=yes > load printers=yes > workgroup=WORKGROUP > [home] > create mode = 0777 > comment = home > browseable = no > writable = yes > valid users = %U > directory mode = 0777 > path = /var/services/homes/%U > > [homes] > invalid users=nobody,nobody > valid users=nobody,nobody > comment="User homes (mount 'home')" > path=/volume2/homes > guest ok=yes > browseable=no > fileindex=no > mediaindex=yes > edit synoacl=yes > win share=yes > skip smb perm=yes > enable recycle bin=yes > recycle bin admin only=no > hide unreadable=no > ftp disable list=no > ftp disable modify=no > ftp disable download=no > read list=nobody,nobody > write list=nobody,nobody > writeable=yes > > ===================================> >That is the weirdest smb.conf I have ever seen, you appear to have two homes shares, the one you would use on an AD DC '[home]' and the standard '[homes]', in the later 'nobody' is an invalid user (twice), yet on the next line 'nobody' is a valid user (again twice). There are what appears to be multiple unknown to 'man smb.conf' lines, if these are valid for your version of Samba installed on your NAS, then you might be better of asking Synology for help. If you have modified the smb.conf yourself, then it might be better to put it back to what it was and starting again. Rowland
On Wed, Jan 06, 2016 at 06:36:50PM +0100, Andreas Maier wrote:> Hi, > I have started using symbolic links on an SMB share and find that > symbolic links whose target no longer exists cannot be removed on > the client side. > > Example, on the SMB client side in an SMB-mounted directory: > > 1. Create a file and a relative symlink to it: > > $ touch a > $ ln -s a b > $ ls -l > total 0 > -rw-rw-r--. 1 andi andi 0 Jan 6 14:42 a > lrwxrwxrwx. 1 andi andi 1 Jan 6 14:42 b -> a > > 2. Removing the symlink target causes removal of symlink to fail: > > $ rm a > $ ls -l > total 0 > lrwxrwxrwx. 1 andi andi 1 Jan 6 14:42 b -> a > # With colors on, the b and a are now marked red, indicating a > broken symlink > $ rm b > rm: cannot remove ‘b’: No such file or directory > $ ls -l > total 0 > lrwxrwxrwx. 1 andi andi 1 Jan 6 14:42 b -> a > > 3. Reestablishing the symlink target causes removal of symlink to > work again: > > $ touch a > $ ls -l > total 0 > -rw-rw-r--. 1 andi andi 0 Jan 6 14:44 a > lrwxrwxrwx. 1 andi andi 1 Jan 6 14:42 b -> a > $ rm b > $ ls -l > total 0 > -rw-rw-r--. 1 andi andi 0 Jan 6 14:44 a > > The same test when performed on a local file system, works fine > (i.e. the broken symlink can successfully be removed). > > I have debugged this on the server side by enabling debug logs in > the Synology NAS, and the relevant portion during the "rm b" command > on the broken symlink is (the directory is Projects/xx/try1, > relative to the SMB share):Can't reproduce this on latest 4.3.x (and I just tried). We did have such a bug, but I remember fixing it :-). What Samba version is running on the Synology ?
Am 06.01.2016 um 19:28 schrieb Jeremy Allison:> Can't reproduce this on latest 4.3.x (and I just tried). We did have > such a bug, but I remember fixing it :-). What Samba version is > running on the Synology ?Jeremy, The smbd version is 4.1.18, according to the NOS value shown in /proc/fs/cifs/DebugData on the client side, and according to "smbd -V" on the server side. I have no control over the samba level on the server side (other than upgrading the Synology firmware). So if this has been fixed in a version after 4.1.18, it would be good to know for sure, then I can create a request for Synology to upgrade their included samba version. Andy
Am 06.01.2016 um 19:16 schrieb Rowland penny:> That is the weirdest smb.conf I have ever seen, you appear to have two > homes shares, the one you would use on an AD DC '[home]' and the > standard '[homes]', in the later 'nobody' is an invalid user (twice), > yet on the next line 'nobody' is a valid user (again twice). There are > what appears to be multiple unknown to 'man smb.conf' lines, if these > are valid for your version of Samba installed on your NAS, then you > might be better of asking Synology for help. If you have modified the > smb.conf yourself, then it might be better to put it back to what it > was and starting again. > > RowlandRowland, I have not modified the smb.conf directly (only indirectly through the Synology user interface), but it definitely has a long history, over several major and minor DSM versions... I have no problem working with Synology, but I thoiught an error like not removing broken symbolic links is something they would have to discuss with the Samba development team anyway. So I came here directly, and hope to get details I can use in a discussion with Synology. Synology has a default smb.conf in /usr/syno/etc.default/. The trouble with starting from that default smb.conf is that I don't know what magic Synology has implemented in addition to the plain samba support. So if I can get some insight without having to do that, I would prefer that. Let's see what Jeremy comes up with. Andy