(My) Vb5.4.4 don't delete attach file on disk...

[LemonMiao]

Is data-write the same user that the web server is running under? data-write doesn't need to be able to write to these directories for files to be deleted. The web server user needs to be able to read and write to these directories. If the web server user is any user except data-write, then it cannot write. If that user cannot write, it cannot delete.

vBulletin doesn't set permissions on the files that are attached. It uses the default permissions of the file system for those directories. It would be a poor practice if we tried to create our own permissions. That would be considered a security hole. We can't trust the environment to be secure if we do this.

Hi Wayne Luke, I opened a ticket to the support to see if they can understand where the problem is, accessing the server.

Thanks for support.

[Wayne Luke]

Is data-write the same user that the web server is running under? data-write doesn't need to be able to write to these directories for files to be deleted. The web server user needs to be able to read and write to these directories. If the web server user is any user except data-write, then it cannot write. If that user cannot write, it cannot delete.

vBulletin doesn't set permissions on the files that are attached. It uses the default permissions of the file system for those directories. It would be a poor practice if we tried to create our own permissions. That would be considered a security hole. We can't trust the environment to be secure if we do this.

[LemonMiao]

I wrote a small php file to do a "simple" test to see if www-data can write to the attach directory and if it can delete the file.

Both tests were successful.

The end result is "yes directory it is writable" and "1" (true)
I do not understand why vbulletin creates attaches not in 777

<?php

$is_writable = file_put_contents('/att/1/dummy.txt', "hello");

if ($is_writable > 0) echo "yes directory it is writable";

else echo  "NO directory it is not writable";

if ($is_writable > 0)  {
$rm = unlink('/att/1/dummy.txt');
echo "<br>ecco rm $rm <br>";
}

[LemonMiao]

All the files and sub-directories within the attachment directory have to be chmod 0777 as well. Not just the directory but all of its contents. You haven't touched the permissions within the attachment directory. They all need to say rwxrwxrwx when list them at the command line.

If you can't set the permissions properly, you need to discuss the issue with your hosting provider or Server Administrator.

Hello, the files I copied here, with the permissions to read and write for the owner, are files that created vbulletin after giving 0777 to the attachment directory.

Is there any way to check (maybe with a php test file) if php 7.2 writes the files well?

[Wayne Luke]

All the files and sub-directories within the attachment directory have to be chmod 0777 as well. Not just the directory but all of its contents. You haven't touched the permissions within the attachment directory. They all need to say rwxrwxrwx when list them at the command line.

If you can't set the permissions properly, you need to discuss the issue with your hosting provider or Server Administrator.

[LemonMiao]

Those permissions are not 777. The attach files are 600 and the thumbs are 644.

Go to the parent of your attachment directory and run chmod -R 0777 /attachment (or whatever its name is). If your (www-data) user has permission to login via SFTP, then you can change these permissions with FileZilla. Right-click on your attachment directory. Check all the permission boxes, set the recursive box and click Okay.

Alternatively, you can make sure that all files are owned (chmod) and grouped (chgrp) by the same user that your webserver runs under. Usually apache. Then you can chmod them 600 or 644. However if you use this method and access SFTP or SSH with another user name, then you won't be able to edit or delete them.

Hi Wayne Luke, I followed all the steps you listed:
The attachment directory (att) has these permissions:
drwxrwxrwx 13 www-data www-date 4096 Sep 18 13:57 att /

But the user directory (in test) created attachments like this:
-rw-r - r-- 1 www-data www-data 3428 oct 8 20:18 5954449.thumb
-rw ------- 1 www-data www-data 87887 oct 8 20:18 5954449.attach
-rw-r - r-- 1 www-data www-data 5563 oct. 8:18 pm 5954450.thumb
-rw ------- 1 www-data www-data 384230 oct 8 20:18 5954450.attach
-rw-r - r-- 1 www-data www-data 5406 oct 8 20:18 5954451.thumb
-rw ------- 1 www-data www-data 288661 Oct 8 20:18 5954451.attach

The user directory is with these permissions:
drwxrwxrwx 2 www-data www-data 12288 Oct 8 20:18 6 /

I really do not know what test to do to make checks.

Edit: important
I forgot to mention that the attachment (att) directory is a link to a directory outside www
My dir www: /var/www/
Attachment: /att/

[Wayne Luke]

Those permissions are not 777. The attach files are 600 and the thumbs are 644.

Go to the parent of your attachment directory and run chmod -R 0777 /attachment (or whatever its name is). If your (www-data) user has permission to login via SFTP, then you can change these permissions with FileZilla. Right-click on your attachment directory. Check all the permission boxes, set the recursive box and click Okay.

Alternatively, you can make sure that all files are owned (chmod) and grouped (chgrp) by the same user that your webserver runs under. Usually apache. Then you can chmod them 600 or 644. However if you use this method and access SFTP or SSH with another user name, then you won't be able to edit or delete them.

[LemonMiao]

Check your settings. Make sure that the Web Server User has permission to read and write those files. We generally say that the Attachment directory should be a recursive 777 so they can be maintained by the webserver user but also available via SFTP and SSH users without having to use sudo.

I am sure that the attachment directory has the 777 and is of the www-data usergroup, but I do a thorough check.
I have no errors in the php, nginx or ubuntu logs ...

edit:
I have reset (even if they were already) all directories with owner www-data and chmod 777
I saw that vbulletin creates the files in the attach directory like this:
-rw------- 1 www-data www-data 246071 ott 6 09:37 5954364.attach
-rw-r--r-- 1 www-data www-data 3235 ott 6 09:37 5954365.thumb
-rw------- 1 www-data www-data 151544 ott 6 09:37 5954365.attach
-rw-r--r-- 1 www-data www-data 3005 ott 6 09:37 5954366.thumb
It's correct?

I now have a way of repeating the deletion process to the forum of all attachments that have not been deleted?

Thanks Wayne Luke

[Wayne Luke]

Check your settings. Make sure that the Web Server User has permission to read and write those files. We generally say that the Attachment directory should be a recursive 777 so they can be maintained by the webserver user but also available via SFTP and SSH users without having to use sudo.

[LemonMiao]

Hi, I recently updated vbulletin 4.2.4 to 5.4.4.

I have php 7.2, mysql 5.7 and nginx 1.14
Attachments are saved on the hard disk.

I tried to load attachments and then delete them, but the files remained in my user's profile folder on the hard drive.
I tried to do hourly cleaning (1 and 2) without any results.

I have not found any errors in the "scheduled task manager" or php / nginx logs.

Are there any other checks that I can do?

Thank you.