[Samba] Cannot remove symlink with missing target
Rowland penny
rpenny at samba.org
Wed Jan 6 18:16:31 UTC 2016
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
More information about the samba
mailing list